Bug#211784: Not just nis...
reassign 211784 dpkg
retitle 211784 dpkg: start-stop-daemon --stop does not check the actual process termination in default
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
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.