[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#211784: Not just nis...



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



Reply to: