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?
signature.asc
Description: This is a digitally signed message part
-- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
