systemd (Was Re: tmpfs for strategic directories)

[Lennart Poettering]

On Tue, 25.05.10 09:00, Jeff Spaleta (jspaleta at gmail.com) wrote:

> 
> On Tue, May 25, 2010 at 7:45 AM, Lennart Poettering
> 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.

Yes, if we'd adopt systemd in F14, then this would indeed be very
quick. But as mentioned, I have not proposed it yet, and while I
currently leaning towards that yes, I will propose it, I'll make my mind
up later about this.

There is no need to convert all services to the native format
right-away. Even normal SysV scripts should boot a little faster with
systemd, since we parallelize them to the level the LSB headers allow
that.

systemd plus the current scripts makes things a bit faster, systemd plus
native unit files should make things quite a bit more faster.

If we chose to adopt it for F14 it would probably a good idea to have
native files for everything that is installed by default at least. I
have mostly written those files now, so this goal should not be too hard
to reach, if we can convince all the maintainers involved to include
them in their packages.

Regarding CUPS: systemd supports all triggers for service startup that
launchd supports, and Apple (who develops CUPS) is starting it via
launchd, on demand. Not sure how nicely CUPS-on-MacOS translates to
CUPS-on-Fedora, but we can do things at least as nicely as they are on
MacOS. There, CUPS is started whenever

1. a local printer is plugged in
2. a local client wants to access its services
3. there's a file in the printer queue, possibly from before the last reboot

We can translate those rules 1:1 for systemd. And then we could
optionally add one more rule:

4. start cups anyway, on boot.

That way we would still benefit from the fully parallelized bootup the
socket based activation allows, but of course lose the on-demand
nicety. Implementing rule #4 means adding a single symlink in
/etc/systemd/system. We could for example choose to not have that
symlink by default, but ask the administrator to create it if he sets up
a multiplexing print server the way Tim suggested.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4