Upstart: feature questions and test code

[Garrett Cooper]

On Tue, Jun 10, 2008 at 3:15 PM, Scott James Remnant <scott at netsplit.com> wrote:
> On Tue, 2008-06-10 at 14:45 -0700, Garrett Cooper wrote:
>
>> My name is Garrett Cooper and one of the groups I'm a part of at
>> Cisco is in charge of finding a process management tool in the IOS ->
>> Linux porting project currently in place. upstart is an excellent
>> candidate for this work.
>>
> Nice to meet you.

You too Scott :).

>> A few feature questions, first off:
>>
>> From README:
>>
>>   "supervising them while the system is running."
>>
>>       What method is used to monitor processes? Does upstart stay
>> resident in memory checking to ensure that all forked processes are
>> healthy, or does it poll attached PID data, etc?
>>
> Simple: like every other UNIX process, Upstart will receive SIGCHLD
> should any of its children terminate.
>
> In addition, since it's pid#1, daemon process are reparented to it, so
> it will also receive SIGCHLD when they die.
>
> To supervise daemon processes, it obviously needs to know their pid - so
> it uses ptrace on the executable to follow the fork() and exec() calls.
>
> This is a stop-gap solution with what we can do today.  I'm also looking
> into interesting things with the kernel cgroups system, that might allow
> us to extend the kernel such that a group controller process (such as
> Upstart) could be notified when any process in the cgroup is reparented
> to it - so it wouldn't need to ptrace.

That sounds like a nice feature! However, my concern is how soon do
you plan to move to that kernel interface? Many groups stick with
older kernels (Nova / Cisco in particular -- we're stuck on 2.6.17
moving on to 2.6.22 soon I think...), so if the feature gets used
sometime in the near future, many groups might not be able to migrate
right away.

Just a note of concern.

(IIRC) ptrace is pretty solid though, which is good.

>>   " * events may also be generated at timed intervals, or when files
>> are changed (not yet implemented);"
>>
>>       What exactly is meant by the term "events"? Is that an
>> abstraction for cases where process(es) die / become defunct or where
>> soft / hard deadlines are established for action to take place with a
>> specific process or set of processes?
>>
> Events are a core concept for Upstart.  They represent changes in system
> state, changes in job state, etc. think of them as a bunch of
> environment variables with a name.

Ok. Just making sure, as the term events can vary between programming
practice and different software realms.

>>       Is the initd literally replaced by a copy developed by the
>> upstart group, or has this been moved over from sysv (a little bit?)?
>>
> Upstart is an init daemon, yes.

Maybe my point of confusion was from this wording in the README file:

 * bi-directional communication with init daemon to discover which
   jobs are running, why jobs failed, etc.