Not only to save time and resources, but also it's a way for the server
to be able to report to the client which CPUs are available for
compilation. It will favour those which are less busy.

On Tue, 2024-12-17 at 16:26 +0800, William Kenworthy wrote:

My understanding is that its so there are free processes ready to go
(it
takes time and resources to spawn a new process) ... its normal on my systems.

BillK

On 17/12/24 01:11, Jorge Almeida wrote:

I have this in the output of "ps axf"

  532 ?        SN     0:00  \_ /usr/bin/distccd --user distcc -- daemon
--no-detach --log-stderr --log-level notice --port 3632 --listen 192.168.1.131 --allow 192.168.1.128
  536 ?        SN     0:00  |   \_ /usr/bin/distccd --user distcc --daemon --no-detach --log-stderr --log-level notice --port 3632
--listen 192.168.1.131 --allow 192.168.1.128

Process 532 is what it is supposed to be. But why the child 536?
Not
to mention 17 more children just like 536, which I didn't paste.
The distccd daemon is alive but not really working, as it has
nothing
to do: I use this about once  a week (for world updating,
eventually
kernel compiling), and today the 192.168.1.128 client is not even
on.
I checked the distccd log, nothing there. The connection is by
ethernet cable. distccd works just fine when required to.

So, what could lead it to spawn so many useless children? I
couldn't
find anything in the manual, and googling doesn't seem to help.

Any distcc user in the same boat?

Thanks

Jorge Almeida

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

My understanding is that its so there are free processes ready to go (it
takes time and resources to spawn a new process) ... its normal on my
systems.

BillK


On 17/12/24 01:11, Jorge Almeida wrote:

I have this in the output of "ps axf"

  532 ?        SN     0:00  \_ /usr/bin/distccd --user distcc --daemon
--no-detach --log-stderr --log-level notice --port 3632 --listen 192.168.1.131 --allow 192.168.1.128
  536 ?        SN     0:00  |   \_ /usr/bin/distccd --user distcc --daemon --no-detach --log-stderr --log-level notice --port 3632
--listen 192.168.1.131 --allow 192.168.1.128

Process 532 is what it is supposed to be. But why the child 536? Not
to mention 17 more children just like 536, which I didn't paste.
The distccd daemon is alive but not really working, as it has nothing
to do: I use this about once  a week (for world updating, eventually
kernel compiling), and today the 192.168.1.128 client is not even on.
I checked the distccd log, nothing there. The connection is by
ethernet cable. distccd works just fine when required to.

So, what could lead it to spawn so many useless children? I couldn't
find anything in the manual, and googling doesn't seem to help.

Any distcc user in the same boat?

Thanks

Jorge Almeida

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 16/12/24 à 18:11, Jorge Almeida a tapoté :

Any distcc user in the same boat?

Yes. How many CPU cores do you have ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 17/12/24 à 11:02, Jorge Almeida a tapoté :

On Tue, 17 Dec 2024 at 08:18, netfab <netbox253@netc.eu> wrote:

Le 16/12/24 à 18:11, Jorge Almeida a tapoté :

Any distcc user in the same boat?

Yes. How many CPU cores do you have ?

8 + 6

Here is my assumption : in man distccd we can read :

-j, --jobs JOBS
Sets a limit on the number of jobs that can be accepted
at any time. By default this is set to *two greater than
the number of CPUs on the machine*, to allow for some processes
being blocked on network IO. (Daemon mode only.)

I think that the distccd daemon spawns one thread for each potential
accepted job. In your case, 8+6+2 = 16

In my case, I have 4 cores, and 6 distccd waiting threads.

Do you have 16 threads below the main distccd process ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)