On 2005-07-03 19:11:16 -0700, Robert Spier wrote: > > Forkserver tends to die with segmentation faults in the signal handler > > as several people on the list noticed. It also sometimes misses the > > death of a child. This patch moves the REAPER into the main loop. It now > > checks for dead children after each accept and once every second if > > there are more then $MAXCONN children. > > It's working fine for a lot of folks without the patch.
Probably yes. I don't think Justin Erenkran, Brian Grossman and me are
the only ones who use forkserver, but that's at least three people on
the list who did have the problem. It may be related to the perl version
or OS, but since Justin is running 5.8.6 on BSD and I'm running 5.6.1 on
Linux that doesn't seem too likely.
Of course if you restart the server automatically if it goes down, you
may even notice that it crashes. It took me some time to figure out why
Nagios complained about once per day that the SMTP server was down.
> One big negative though - your patch adds tabs to a file that uses
> space indentation. Please be consistent.
Sorry about that. Default behaviour of vi(m). I'll run files through
expand next time before making patches. (If anybody has a good idea how
to reconfigure vim according to the directory tree I'm in, I'm all
ears - I'm using local .vimrc files, but that's one per directory which
is a bit of a pain in a deep directory structure).
[quoting restructured a bit]
> > This means that zombies hang around until the next client connects.
> > A bit untidy, but shouldn't be a real problem.
> > forkserver has been rock-solid for me since this patch.
>
> As for the rest of the patch, there's a potential downside which is
> that children will hang around until the next connection comes in.
> Generally that's relatively soon - but not necessarily. So any
> resource cleanups that happen won't happen until some point in the
> future. I know thats a nit... but still something to think about.
Yep. I wrote that above. Generally, I think that's mostly an aesthetic
problem.
The child processes have died, and hence freed all their memory, closed
their files, etc. All they still occupy is a slot in the process table.
So unless you have an extremely spikey behaviour, where hundreds of
clients connect at once and then there are absolutely no connections for
a long time, that shouldn't be a real problem.
There are also some resources held by the parent. Currently that's only
one small hash. People may come up with uses for the post-connection
hook where a prolonged time between the death of the child and the hook
being called may be detrimental - that may be a real problem, but right
now I can't think of any plausible scenario.
hp
--
_ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig
|_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken.
| | | [EMAIL PROTECTED] |
__/ | http://www.hjp.at/ | -- Holger Lembke in dan-am
pgpxWbXMX4rhP.pgp
Description: PGP signature
