Bug#727708: upstart proposed policy in Debian

[Colin Watson <cjwatson@debian.org>]

On Sat, Dec 14, 2013 at 01:36:59PM +0000, Ian Jackson wrote:
> How will we cope with removed-but-not-purged services ?

Somebody else can perhaps provide a better answer, but I'd note that
this situation will generally just result in a log file complaining that
the executable in question doesn't exist (and of course the service
never reaching the "running" state, but that was expected), which isn't
particularly awful.

> Do we deprecate "expect fork" and "expect daemon" ?  (I would favour
> this - the approach there is pretty horrible.)

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.  It's trivial to patch
into existing code and generally also trivial to maintain such a patch.
This protocol is simple enough that it's very easy to reason about,
which is helpful when investigating problems relating to service
startup, and it requires no particularly exciting code in the init
daemon since finding out about SIGSTOP already basically comes with the
territory of being pid 1.

I think we'd have to do some work to modify existing Upstart jobs to
conform to this, but I also think that work would be worthwhile, as
"expect fork" and "expect daemon" have been a bit flaky and they're a
bit of an obstacle (perhaps not an insurmountable one) to porting to
non-Linux kernels.

-- 
Colin Watson                                       [cjwatson@debian.org]