Bug#211784: Not just nis...
On Mon, Sep 22, 2003 at 12:29:53PM +0900, GOTO Masanori wrote:
> At Sat, 20 Sep 2003 10:32:25 -0300,
> Cesar Eduardo Barros wrote:
> > I've also seen this with snmpd in a friend's box (the upgrade stopped
> > it, it didn't load, and a few hours later he noticed mrtg was
> > misbehaving). That box is a genuine Pentium MMX 200, so it's no surprise
> > stopping something takes a bit longer than usual.
>
> Interesting, yes, this NIS and slow machine issue is problem.
>
> > I think the mistake is in the rc.d scripts, which don't wait for the
> > program to really quit before returning from the stop action. Increasing
> > the delay before restarting is just a kludge, you can still lose the
> > race.
>
> I'm surprised. Is this true? If so, this is start-stop-daemon fault...
>
I don't know, but I have seen this happen (and because of this I tend
not to use restart; I use a manual stop/start, and let the extra delay
caused by typing the options help). A lot. (I tend to use either slow
boxes or underpowered boxen, or even both)
I have also seen scripts with things like "sleep 1" or "sleep 5" in them
in the restart case (try "fgrep sleep -r /etc/init.d" to see what I
mean). Some of them use start-stop-daemon, some don't. And even then
it's not enough (if the sleep delay is 1 second but my box is trashing,
it could be 10 or more seconds before the process manages to die -- and
if it was on swap it's worse.)
I don't believe start-stop-daemon has any guarantees about the process
finishing; the man page only says it sends a signal (btw, the manpage
has those ugly non-escaped hyphens). --retry with a infinite timeout
(which nobody does) would be a way to avoid the races (but then you have
issues on shutdown with processes stuck in unkillable states...)
--
Cesar Eduardo Barros
cesarb@nitnet.com.br
cesarb@dcc.ufrj.br
Reply to: