reassign 211784 dpkg retitle 211784 dpkg: start-stop-daemon --stop does not check the actual process termination in default thanks
At Mon, 22 Sep 2003 13:07:27 -0300, Cesar Eduardo Barros wrote: > 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...) I'm looking through this bug again. As you wrote, I think start-stop-daemon does not wait in default. One way to fix this bug is to use --retry with timeout value. start-stop-daemon --retry can confirm whether the target process is still running or not, using /var/run/*pid + /bin/ps. Frankly speaking, this is start-stop-daemon lazyness. At shutdown, start-stop-daemon does not guarantee that processes are really stopped. It's awful thing. Unfortunatelly, we debian-glibc cannot do anything than changing sleep variable. I think start-stop-daemon should check the finish of processes. However, this may not be fixed until sarge is released, so I change sleep variable from 1 to 2. But it's just work around. I reassign this bug to dpkg. If I have wrong understanding, please let me know. Regards, -- gotom
