Upstart: feature questions and test code

[Scott James Remnant]

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.

> Due to legalize we're in limbo right now awaiting the AOK to
> import upstart into our SCM. However, we're still doing research tasks
> trying to determine what, if any features are missing, how should the
> code be tested, and how can we contribute any non-Cisco specific
> improvements back to the upstart community.
> 
Great, looking forwards to working with you!

> 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.

>   " * 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.

>       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.

> About testing:
>       Currently the code is organized into one large C-file with what
> appears to be whitebox only tests of the APIs. Has some thought been
> put into how, if at all possible, it is to generate black box tests as
> well for the code?
> 
Black box testing is made difficult by the fact that much of Upstart's
functionality is not accessible unless it is the init daemon.

This may become easier with a move to cgroups.

>       Has anyone considered reorganizing the test code or adding
> additional tests to upstart?
> 
It's not high on my priority list.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20080610/86f6bf75/attachment.pgp