Upstart: feature questions and test code

[Casey Dahlin]

Garrett Cooper wrote:
> Hello,
>       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.
>       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.
>       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?
>
>   

Upstart responds to sigchld to detect when its child processes die, and, 
naturally, keeps an internal table to track what pid belongs to what 
actual service. Currently care has to be taken to ensure processes don't 
fork away as upstart will lose track of them. There are various 
solutions to this, one of which was the use of ptrace, the other, more 
recent one being the use of cgroups (a new kernel feature in 2.6.25).

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

Upstart is "event driven." All action occurs in response to events. 
Events can occur when hardware becomes available or goes away, when 
devices become ready, or when programs request a specific service. For 
example, if you were running Apache on a machine, you might add this 
line to the job config:

start on network-available

Which would cause Apache to start whenever the network became available 
(assuming that udev or whatever hardware management facilities you are 
using were programmed to cause this event).

Incidentally, Upstart does not natively have any concept of runlevels. 
Most distros simulate runlevels within upstart using special events in 
order to ease their transition toward the event driven model.

>       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 was written anew from the ground up.

> 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?
>
>       Has anyone considered reorganizing the test code or adding
> additional tests to upstart?
>
>   

For this you will have to ask Scott (the actual maintainer of Upstart). 
I'm sure he'll reply to this thread shortly.

To make black box testing possible, you would likely need a virtualized 
environment (since rebooting and manipulating the state of the OS are 
inherent parts of upstart).

> Thanks and I look forward to your reply,
> -Garrett
>
>   
No problem :)

-CJD