On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote: > > By the way, upstart uses ptrace for this: > > http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ > > It's an interesting trick, and probably more portable too. > It's an ugly hack, even Scott didn't like that approach very much and > definitely one of the weaker points of upstart. Scott was planing on > reworking process tracking using a netlink based interface. > It's rather easy to confuse upstart's process tracking. You explicitly > have to tell upstart if a daemon forks once or twice (expect daemon, > expect fork) and if the daemon forks multiple children upstart often > doesn't get it right. > systemd's usage of cgroups solves all those problem very nicely. The use of ptrace for process tracking is ugly, but that has nothing to do with the need for 'expect daemon' or 'expect fork'. You still need to have some way of deciding when the service should be considered *started*, and the rules are going to be different for each service. Using cgroups might make the difference between 'expect fork' and 'expect daemon' immaterial, but cgroups alone will *not* give you a race-free startup. systemd says you should avoid races by using socket-based activation for everything; I'm not convinced this is actually superior for anything except the desktop case, but in any event it means you would still get races for anything not (yet) using socket activation if you don't have some clearer notion of what it means for a job to be "running". There are also complications to using cgroups, in that suddenly any service that needs to be able to spawn long-running processes that outlive the service has to start caring about cgroups - both so that they survive the service being shut down from the outside, and so that the supervisor knows not to count these processes as evidence that the service is still running. ssh is going to be the first problem in this regard, though I'm sure there will be others. Has someone patched openssh to be cgroup-aware? > upstart on the other hand implements sysv compatibility completely > different. All it does is run "/etc/init.d/rc 2" on the runlevel 2 > event. You can't really declare any interdependencies between upstart > and sysv services. There is a patch available to startpar, linked in this thread back when we were actually talking about upstart :), that provides support for such interdependencies. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature