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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
