[openssh] Re: sshd takes 15 minutes to start

[Peter Stuge]

On Sat, Aug 02, 2003 at 03:53:22PM -0500, Ben Lindstrom wrote:
> On Sat, 2 Aug 2003, Peter Stuge wrote:
> > On Fri, Aug 01, 2003 at 01:58:34PM +1000, Darren Tucker wrote:
> > > I don't know if ssh-rand-helper can do anything sane about this....
> > > possibly set a timeout for a few seconds, kill -9 the errant command,
> > > then abandon it and let init clean it up if it exits?
> > > Comments/suggestions anyone?
> >
> > This is a good idea.
> 
> kill -9ing may not be a bad idea for things that don't honor "please shut
> down now", but I don't like the idea of abandoning the child process.

An alternative to that and the current hanging is to fork(), but maybe it's
just best to leave it as is, see below.


> If an OS company is not coding things to be signal safe and it now becomes
> a zombie it may be out there until a reboot at worse.  Quietly filling up
> the pid table.

Yes, this is really bad. Could the netstat process be expected to disappear
if the parent process exits, or would it still be left?
(Kill the shell in Darren's suggested test..)


> I'd be more concern about older UNIXes lacking a /dev/random to start with
> since coding quality for race conditions was.. well.. =) Not always on
> par.
> 
> > In order to catch this problem, I know I would want a notice of some sort.
> > Otherwise it might lead to a lot of defunct processes that suddenly show up
> > out of nowhere.
> > (Or after a major update, when many things have changed at once..)
> 
> Agreed.  However, keep in mind ssh-rand-helper was designed as a stop-gap
> measure.  You really should be looking for a /dev/random kernel module or
> a longer standing entropy process like prngd.

Well, do people seem to do this?
Myself, I have /dev/random, and would indeed get prngd otherwise. Maybe the
question is how easy we want life with ssh-rand-helper to be?


> > An option to leaving the process to init is to fork() ssh-rand-helper to
> > show more clearly what's going on, but the log or stderr message is now even
> > more important, since this will obviously use up twice as many PIDs.
> >
> [..]
> 
> >From here below I'm not following what your saying.

Sorry, I should've been more clear. OTOH, it was just wishful thinking.

I was thinking that the kernel has ultimate ability to clean up processes,
and that a usage limit set by ssh-rand-helper could be one way to use that
ability. Not all kernels (any?) keep track of/have limits for real time
though, only CPU time, so it doesn't work. And at least Linux sends SIGKILL
when the hard CPU time limit is reached, that's another reason it doesn't
work, although I'd hope that the kernel would really be able to remove a
process when it wants to. Admittedly, I lack some pieces of the kernel/user
puzzle, though.


//Peter