Martin Gregorie wrote:
Yeah - maybe there is some indication in the log? I think there is a
switch that determines how many emails a child will process before
needing restart. (just looked it up: --max-conn-per-child)
I just checked my logs, during the last 9 hours I have 6016 of these:
spamd[11362]: spamd: handled cleanup of child pid 14010 due to SIGCHLD
Is that the one you mean?
That's the only log message I've seen. Sometimes you can associate it
with a scan that exceeded --timeout-child seconds and sometimes, much
more rarely, it happens after a scan taking two or three seconds.
I don't know if that is happening on my systems too, I haven't checked.
I wonder if the latter could be caused by the maintenance of spare
child processes?
There are also arguments for controlling minimum/maximum number of spare
child processes - if your load varies, and you have a significant
difference between min and max, I could see that leading to more child
processes stopping and starting.
Does the parent or the child determine whether the child stays alive
after completing a scan or whether it should terminate?
It's the child that determines that "Uh, I've done X scans, all done".
It's just a for-loop:
for( i=0; i<maxscansperchild; i++ )
wait for work
do work
If it's about pruning idle child processes, the parent is no doubt doing it.
/Per
