Colin Watson <cjwat...@debian.org> writes: > For cases where simply running the daemon in the foreground is > insufficient (i.e. it's important to know more accurately about service > readiness), I personally prefer "expect stop". While raising SIGSTOP > when they're ready isn't generally something daemons already support, it > also normally has no other conflicting meaning.
Is there a more complete explanation of this somewhere? The cookbook is rather short on details. Assuming that this means the daemon sends SIGSTOP to itself when it's ready to accept connections, I find this completely counter-intuitive and exceedingly strange. Wouldn't this cause the daemon, if run outside of upstart, to do nothing in an extremely confusing fashion? I assume upstart is using waitpid to wait for the child to be stopped and is sending SIGCONT, and if you run the daemon outside of that environment, it would just stop itself and never start again. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
