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

Bug#727708: upstart proposed policy in Debian



On Wed, Dec 18, 2013 at 05:42:11PM -0800, Russ Allbery wrote:
> 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.

init(5) says much the same thing, with the addition of this sentence:

  "init(8) will send the process the SIGCONT signal to allow it to
  continue."

> 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.

It makes a lot of sense to me; it's a synchronisation point.  Though it
would be better if it didn't involve the daemon stopping briefly; I'd
also be fine with a better protocol along similar lines, but at least
this has an appealing minimum of setup.  Lennart was talking at DebConf
about doing something similar in principle with IIRC a well-known
socket.  There are trade-offs here in terms of how much extra code you
want to patch into daemons, and whether you think it's reasonable to
make them link to additional libraries (I would prefer not).

> 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.

That would indeed be confusing if it happened, but you wouldn't do the
SIGSTOP thing if not running in an environment supporting this protocol,
so I don't think this confusion should arise.  For a practical
implementation, see the Debian openssh package, in particular:

  http://patch-tracker.debian.org/patch/series/view/openssh/1:6.4p1-1/sigstop.patch

(This just does the quick and easy thing of keying off an environment
variable; when I implemented this in openssh, I opted for that over
looking for some Upstart-specific property because this is trivial to
port to any other hypothetical init daemon supporting the same thing,
and it means that it is also tied to an appropriate job configuration,
not just a suitable init daemon.)

-- 
Colin Watson                                       [cjwatson@debian.org]


Reply to: