Upstart: feature questions and test code

[Scott James Remnant]

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
-- 
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/20080611/ab0bfd57/attachment-0001.pgp