systemd (Was Re: tmpfs for strategic directories)

Lennart Poettering mzerqung at
Tue May 25 18:40:06 UTC 2010

On Tue, 25.05.10 13:15, Simo Sorce (ssorce at wrote:

> > My one concern about the current discussion is that the decision to
> > move to systemd in the timeframe of F14 is being rushed ahead of the
> > aforementioned technical judgement.  I can understand your personal
> > enthusiasm for the move as you are intimately familiar with systemd.
> > But I'm not sure its adequate to rush ahead until we all have a better
> > feel on how this works in practise... and how much work its going to
> > take to convert all our existing packages to systemd styled startup.
> > The back and forth on your blog between yourself and Tim Waugh about
> > cups service activation, for example, is something I think we all need
> > to understand.  I think there is a lot buried in that discussion about
> > how complex some of our existing services are going to look under
> > systemd styled configuration.
> I second that.
> I'd like to remember that there are *many* upstreams are going to
> resistant to this change. A lot of upstream projects need to be
> compatible to a lot of Linux and Unix systems, even old ones, so before
> they move they want guarantee that this is really going to be the next
> thing. That means that until most distributions start using systemd
> they are not going to do the work.

They don't *need* to move. It's not an exclusive disjunction, that you'd
have to support either systemd or not systemd. You can easily support
both systemd activation and classic sysv from the same binary. The 10
daemons we have patched so far only needed about 10 lines of changes
each to become socket-activatable. And those changes are nops unless
$LISTEN_FDS is set.

Or in other words: moving to systemd is a gradual process, where for
every service we can decide indivdually how we want to do it:

1) continue use a classic sysv init script
2) provide a native unit file
3) provide a native unit file and do socket/bus based activation

And all that for the same binary.

As mentioned I have now patched the 10 daemons or so we ship by default
(and a few more) to become socket activatable. If we can merge those
upstream and into our packages we already are a big step ahead and
everything else can come later.


Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net           GnuPG 0x1A015CC4

More information about the devel mailing list