Dear Maintainer,
after inspecting start-stop-daemon's source, i couldn't find any wait/waitpid
calls, and they should exist.

Stopping a daemon usually consists in sending a message to the right pid, but
after that it would be better to do a waitpid so that the command terminates
when the daemon has really stopped, not just when the signal has been sent.

This would allow scripts to be simpler because they would know that after a
"start-stop-daemon --stop", the daemon has in fact stopped; and it's not the
case right now.

This leads maintainers to insert sleeps in the scripts to hope that in the
meanwhile the daemon will terminate (the correct approach would be to insert
wait on the pid); but the even more correct approach would be to fix
start-stop-daemon so that when it exits the daemon has stopped.

Bash programming isn't usually event-based, so when a command terminates
it is supposed to be done with its job.

Bye

Hi!

That's because those calls only apply to child processes which is not
the case with s-s-d --stop.

That behaviour is already supported with the --retry option. But this
might not cover the case that a parent process in the daemon has
terminated but not some of its worker childs for example, and that's
a daemon's issue.

Then those init scripts are buggy, and should be fixed.

This is either a problem in the daemon, or in the init script, I don't
really see any issue here with s-s-d. If no further information to the
contrary is provided I'll be closing this report.

Thanks,
Guillem

There are alternative safe ways to detect it, like using ptrace or [1].
A cycle with kill(0) is not safe, another process with the same pid could be
started between two iterations.
Agreed, but the kill(0) thing is an hack itself which could not work in all
the situations.
Yes, they should use the --retry instead of the wait.

Bye

[1] http://netsplit.com/2011/02/09/the-proc-connector-and-socket-filters/

Control: retitle -1 s-s-d: Race condition when finding pid and checking it's still running

Well, s-s-d always does the matching checks to find the correct pid on
each loop iteration. But sure, that's still prone to a race condition,
although that's an entirely different problem than the one reported,
as in s-s-d could send a signal to a process it was not intended for,
which is different than exiting before the process has exited. Which
would indicate the sleeps on init script are unrelated to the race
anyway.

Yes, I agree it's not reliable for what is its intended use (checking
that the *desired* process is still running). I'll be implementing for
1.17.x system specific support for listening on process termination
notifications. Most probably ptrace or kqueue on BSDs, ptrace or proc
netlink support on Linux, and something with the proc server on the
Hurd, to be used when available.

Thanks,
Guillem