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 >
