Upstart plans

[James Hunt]

Hi Mark,

On 09/08/11 19:26, Mark Russell wrote:
> On logging events, what's the difference between what you are suggesting
> above and what we have that now with --verbose and --debug?
Primarily that we would then have a central, consistently-formatted event log available. Currently,
you would have to semi-intelligently parse the system log to reconstruct the event list. A
consistent format would mean it would be easy to grep of course. Added to which, the log would/could
be in a known location (regardless of how rsyslog is configured). Also, we could consider adding not
only the event name to the log, but also the events environment. The focus is on job output logging
right now, but adding an event log might be a useful extension. If introduced, it would be togglable
though since you may not want such a log and we would also need an option to specify where to write
such a log (a tmpfs/ramfs location may be best for performance). As mentioned in a previous mail,
I'm interested in the idea of having the event log togglable at runtime via a new initctl command
which would allow more fine-grained control.

>> * Update pid tracking code to use PTRACE_O_TRACEEXIT rather than PTRACE_O_TRACEFORK.
>> * Introduce "expect exit <n>" syntax.
>>
> 
> OOH!  Would this possibly help with:
> https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/738209 ????
Possibly (haven't looked at the code), if the child communicates its state back to the parent before
the parent exits. Autofs seems to be in that category of services that need a way to "announce" that
they are "ready" to service requests since counting forks/exits and checking for the existence of a
pid isn't enough for them. Another example of apps in this category are RDBMS systems which may
start successfully, but whose services are not available to clients until they have finished a
recovery phase (log replay, etc). There seem to be two good possible solutions to this problem:

(1) fix the apps in question so they behave (clearly, not always possible).
(2) employ one of the '"expect stanza" enhancements' (once they're available) to allow Upstart to
determine "readiness" more accurately for specific services that don't adhere -- for whatever
reasons -- to convention.

Where (2) includes having the app itself emit an event signifying readiness (maybe by way of any
trigger framework the app may provide).

>> * Needs to emit "starting" and "started" events for each service it runs.
> 
> Does this mean what I think it means????  Greater Sys V compatibility
> would be absolutely helpful to admins and developers alike.  If I
> understand you right, this would help with a lot of issues that arise
> from mixing Upstart jobs and legacy init scripts that depend on each other.
> 
> I assume you also mean "stopping" and "stopped"(?).
Yes and yes.

Kind regards,

James.
--
James Hunt
____________________________________
http://upstart.ubuntu.com/cookbook
http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf