[HEADS-UP] systemd for F14 - the next steps

[Lennart Poettering]

On Wed, 14.07.10 10:58, Bill Nottingham (notting at redhat.com) wrote:

> 
> Lennart Poettering (mzerqung at 0pointer.de) said: 
> > Since the acceptance by FESCO it has been added to Rawhide together with
> > patched or updated versions of a few related packages. However, what has
> > not been done so far is making it the default in Rawhide. So far it does
> > not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I
> > want to notify everybody that I am planning to do this change very soon
> > now (tomorrow?). Then, systemd will be pulled in onto your rawhide
> > system and is used exclusively for booting (so far, you can still choose
> > between it and upstart in grub, with a default on upstart), and problems
> > booting should be reported to systemd in rhbz then.
> 
> This seems a little backwards. If we want to support both, then we need
> to just leave it as 'Conflicts', and we'll just flip the default in
> comps. By marking it as 'Obsoletes', you effectively make it impossible
> to still boot with upstart, as it will be removed in any yum update.

Well, I don't think we want to support both. I believe F14 should be
systemd and only systemd, but we want the option to revert to upstart
should that not work out.

I am very much interested to get upgraded systems to use systemd as
well, which is why I'd really like to go the Obsoletes way, and use a
versioned Obsoletes, so that we can switch back to upstart if we want to
by another versioned Obsoletes, but this time from upstart. (which is
exactly what James Antill proposed in his mail)

Or in other words: I'd like to make this switch for the whole distro,
not leave it to the individual machines.

So, unless there is really strong opposition to the Obsoletes approach
I'd go on and do the switch?

> I suspect the biggest issue here is confined daemons, as they may
> not have permissions to create their own directories in /var/run or
> /var/lock once they've been started. Unfortunately, it's the sort of
> flag day that we really can't do unless everything in our tree is fixed.

Well, a temporary and kind of ugly fix could be to add lines like the
following into the systemd service files for these services.

 ExecStartPre=-/bin/mkdir -p -Z foo_t /var/run/foo

Or something like that. And for service which continue to use SysV
scripts something similar is easily thinkable in the init scripts. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.