On Tue, Jun 10, 2008 at 3:15 PM, Scott James Remnant <[EMAIL PROTECTED]> 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. >From the above wording, it seems like upstart is working with initd to accomplish the beforementioned goal of replacing sysv initd. Besides that I noticed that there's an init app within the upstarts sourcebase. Hence that should explain my confusion... >> 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. 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. Thanks again, -Garrett -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
