On Thu, Apr 14, 2011 at 3:11 PM, Kees Cook <[email protected]> wrote: > On Thu, Dec 16, 2010 at 08:41:56AM +0100, Thierry Carrez wrote: >> Kees Cook wrote: >> >> /etc/service/status.d >> >> >> >> And if one exists for the job name, run it, otherwise just run the >> >> upstart status and provide an LSB compatible return code. >> >> >> >> This would also allow for the post-start stanza to call the same code if >> >> it is needed. >> >> >> >> Does anyone have strong thoughts on this? Given the service.d approach, >> >> it would seem the correct course of action is to open a feature request >> >> against sysvinit, document it in our upstart job writing best practices, >> >> and to document this feature in the server guide. >> > >> > Why should this be external to upstart? This seems to me like a clearly >> > missing feature in upstart itself. (i.e. a "status" stanza for services >> > that need a non-passive check.)
I agree, and we did talk about it at UDS-Natty in Orlando. SJR disagreed with this vehemently, as I recall. >> +1 on an optional, specific "status" stanza in upstart scripts. When >> present, it could be automatically called as a post-start before >> "started" is emitted, and would also be called when "status" is used. > > Has anything happened with this? Would this make a good UDS topic? I'd think it would be a good one to re-visit, perhaps starting with a brief review of where we left it 6 months ago. This is *definitely* something I personally miss, once an init script is converted to an upstart job. "status $foo" tells me almost nothing interesting for most of my values of $foo today :-( -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
