Upstart plans

Tue Aug 9 18:26:03 UTC 2011

Hi James, Hi upstart-devel,

On 08/04/2011 03:01 PM, James Hunt wrote:
> Hi All,
> 
> Last week, Scott, Steve Langasek (hotfoot from DebConf11!) and myself met to discuss future plans
> for Upstart and work on some new feature ideas. This mail summarises those discussions.
> [SNIP]
> 1.2 Upstart in Chromium OS
> ===========================
>     This was an extremely interesting discussion to understand Chromium OS's
>     use of Upstart. Chromium OS has very strict boot time-allocations for
>     different parts of the system (kernel, X11, etc) so getting an
>     insight into such a specialized boot was highly instructive.
> 

Thanks for explaining Upstart on Chromium/Chrome OS.  It is very
interesting indeed.  It feels like they didn't dispense with Run Levels
as much as reinvent and rename them.  It reminds me a bit of the
separation of functions in RPM-based systems with run levels 1, 3, and 5
-- though of course they're executed quite differently.  In any case,
one of the benefits I see with the Chromium OS boot model is that would
make determining start and stop criteria super easy in most cases.

I hadn't heard anything about this until your post, but I looked into a
bit and found this page that adds a couple of technical wrinkles to what
you wrote up:
http://www.chromium.org/chromium-os/boot-milestones

> [SNIP]
> 2.1 Logging of job output (and maybe events) (bug 328881)
> ==========================================================
> 
>     Pair programming to write minimal logging functionality for jobs. I
>     now have the code working (90% complete for system jobs, excluding
>     tests) such that we will soon introduce a "console log" option
>     (which will be the new default for jobs). Once directory
>     "/var/log/upstart/" becomes available, all output from jobs
>     specifying explicitly or implicitly "console log" will have their
>     stdout and stderr redirected to a file in this directory. Currently,
>     the code is buffering output, so probably makes sense to adopt a pty
>     approach. A complication is logging of user jobs (for a variety of
>     reasons).
> 
>     This feature will be a huge aid to debugging and a boon for
>     Administrators.
> 
>     Could utilize same technique to log events, although need to assess
>     performance impact of this due to numbers of events being emitted.
> 

You had me at /var/log/upstart/.  This would be wondrous.

On logging events, what's the difference between what you are suggesting
above and what we have that now with --verbose and --debug?

> [SNIP]
> 2.3.1 Stage 1 - track exits, not forks
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>       Change Upstart to track processes calling one of the various
>       exit() calls.
> 
>       The advantage of tracking exits being that that it's a better
>       indication of daemonization since the exit() always follows the
>       fork(), and it allows for services whose parent actually stays
>       running until the child is ready, as well as those that the parent
>       dies immediately.
> 
>       Stage 1 Tasks:
> 
> * 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 ????

> 
> 2.3.2 Stage 2 - track all pids
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>       Upstart current tracks only 1 pid / job process type (main,
>       pre-start, etc). By changing it to track *all* pids for all
>       process types, we minimize problems relating to "unexpected" pids.
>       It also lays the foundation for the transition to cgroups.
> 
>       Stage 2 Tasks:
> 
> * Make JobClass->process array a linked list of "Process" objects
>   to allow Upstart to track all pids a process type has been known as.
> * Add ProcessType entry to Process object since can't use index of
>   array any more.
> * Add entry for PROCESS_CUSTOM to ProcessType.
> * Add "char *" name to Process to store name of process type.
> * We can now hanle >1 pids per job process. This fixes a lot of
>   problems. Also paves the way for custom actions (bug 94873)
>   since we can simply add a new entry to the linked list for a
>   new process type "foo" / "monitor", etc.

Everybody wins with custom actions!  This is very exciting.  Being able
to handle arbitrary actions should help with porting Sys V scripts that
have numerous actions in their case statement.  Or where things like
"status" are handled different (like apparmor).

> [SNIP]
> 2.3.3 Stage 3 - introduce cgroups
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

\o/

> [SNIP]
> 3.1.2 insserv/startpart needs to have knowledge of Upstart.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> * 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"(?).

> [SNIP]
> 3.3 "and" issues (bug 447654)
> ==============================
>     As documented in init(5), once a condition becomes true, Upstart
>     discards knowledge of the other parts of the condition tree (by
>     unblocking those events). This causes problems when a condition
>     starts out as false, becomes true, goes false again, but then again
>     becomes true. This can lead to unexpected behaviour and is confusing
>     to users. Due to Upstarts internal design, this is a hard problem to
>     solve and we didn't come up with any workable solutions. More
>     thought required on this one.
> 

Oy.  My nemesis.  This can be worked around with wait jobs as we know --
at least the scenarios I'm thinking of.  Wait jobs work, but they aren't
simple to understand, and in the end they rob Upstart of much of its
elegance and clarity.  Working with them feels like dependency init
again, it feels backwards.

It's too bad there isn't a good solution yet, but I'm glad it's still on
the radar.

> [SNIP]
> Thanks!
> 
> Regards,
> 
> James.

No.  Thank _you_ James.

Mark

-- 
Mark Russell
Premium Service Engineer | Canonical, Ltd.
<mark.russell at canonical.com> | GPG: 4096R/B3BBA7D1

www.ubuntu.com | www.canonical.com