[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upstart: please update to latest upstream version

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

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

Reply to: