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 [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
