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

Bug#727708: upstart proposed policy in Debian



Colin Watson <cjwatson@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: