Upstart: feature questions and test code

[Garrett Cooper]

On Wed, Jun 11, 2008 at 2:10 AM, Scott James Remnant <scott at netsplit.com> wrote:
> On Tue, 2008-06-10 at 17:03 -0700, Garrett Cooper wrote:
>
>> >> 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.
>>
> Kernel tends to operate in a different century to the rest of the world,
> I figure it'd probably be next year before we got that accepted
> upstream, so you're pretty safe for a while :p
>
> I'm not sure I'd remove the SIGCHLD handling either, this would just be
> a new option -- in fact, I may just implement it using SIGCHLD anyway,
> so it'd be compatible.
>
>> >> 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.
>>
>> Ok... good to know.
>>
>> >>       Has anyone considered reorganizing the test code or adding
>> >> additional tests to upstart?
>> >>
>> > It's not high on my priority list.
>>
>> Mmk. Pending that we do get acceptance for using upstart from the
>> Legal Dept then I'll most likely be working with my team to generate
>> some more whitebox tests for upstart, and will also help work out some
>> feature items.
>>
> Any help is always appreciated - you really can never have too much test
> coverage ;)
>
>> Also, just out of curiosity have you heard of / worked with the LTP
>> group before? I'm working with them right now to improve their
>> makefile infrastructure, and we intend to use some of the test
>> reporting features within their libraries to assist with reporting to
>> our internal test harness. Is there any way where you think it may be
>> prudent to use their library as a base for reporting to help reduce
>> test code and make output deterministic?
>>
>> The LTP is licensed under GPLv2.
>>
> I don't know LTP?

Scott,
     Here's the LTP website: http://ltp.sf.net/. They have a number of
test programs contained within the suite and a well-defined output
reporting schemata.
     If you want sample output or shell / C-based API's to look at,
I'll be more than happy to point you to some within LTP.
Thanks,
-Garrett