Control: retitle -1 s-s-d: Race condition when finding pid and checking it's still running
On Mon, 2012-12-03 at 01:28:52 +0100, Salvo Tomaselli wrote: > > That's because those calls only apply to child processes which is not > > the case with s-s-d --stop. > 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. 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. > > 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. > Agreed, but the kill(0) thing is an hack itself which could not work in all > the situations. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
