8:24 p.m.
Heya,
as many of you probably know systemd got accepted as feature for F-14 by
FESCO a few weeks back.
https://fedoraproject.org/wiki/Features/systemd
And in case you want to read up what systemd actually is, here's the
blog post that introduced it (only slightly out-of-date, we have however
advanced a bit since then):
http://0pointer.de/blog/projects/systemd.html
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.
At this point the following packages in rawhide have been updated to
provide socket based activation [Hint: in case you are wondering, socket
activation is one of the amazing things in systemd, see the original
announcement for details]: dbus, udev, avahi, rtkit. Before F14 I want
to at least add rpcbind and rsyslog to this list for socket based
activation, and most likely cups. For rpcbind/rsyslog the patches have
been submitted upstream, and even have partly been merged already).
It would be great if we could ship native unit files (as replacement for
the current sysvinit scripts) for as many packages in Fedora as we can
for F14, and in particular for all those services that are installed by
default. [Hint: unit files is the systemd term for files describing
services (i.e. daemons) and other objects systemd starts and
maintains]. I have prepared native unit files for the majority of
services of the default install, and will now post them on bugzilla
piece by piece for inclusion in the rpms. Ideally, those unit files are
shipped upstream, but they can be added in the rpms too. Unit files are
usually very short for normal services and should be easy to write
(i.e. you don't have to think about dependencies or any complexities
like that at all in most cases, unless you want to do fancy stuff
involving early boot or late shut down). Unit files should be written
for daemons that currently install SysV init scripts and also (and this
matters!) for all services currently started via D-Bus bus
activation. Writing native unit files enables the radical form of
parallelization that systemd employs. Units without native unit files,
i.e. only SysV or D-Bus service files, will only benefit from very
minimal parallelization.
Note that neither patching in socket based activation, nor shipping
native unit files will break services in a non-systemd boot up. In order
to keep our options open to possibly revert things before F14 we
explciitly made sure not to break compatibility with non-systemd
boots. i.e. the socket actviation patches become NOPs if systemd is not
running and the native unit files are ignored, so that only sysv init
scripts matter. Also note that even in the case that we do roll back to
upstart before the release of F14 this work won't be in vain, as work
that has been done has been done and will then becom euseful when we
adopt systemd in the next cycle. I want to stress though that at this
point in time I see no reason to assume that we shouldn't make it for
F14.
So, here's my call for help, in order to make this all a big success:
a) if you maintain a package which includes a daemon/service from the
default install, expect a proposed unit file in bugzilla soon. Would be
awesome if you could check it and add it to your RPM. Even better would
be if you get it merged upstream. I have unit files the majority of
these services. Ping me on irc (#systemd on fdo, I'm 'mezcalero'), if
you wonder whether yours is one of them, and if you have questions.
b) if you maintain a package which includes a daemon/service from
outside the default install, it would be awesome if you could ship
native unit files too, even though I don't have any ready for
you. Writing unit files is not difficult, and should be well documented
in the man pages. In particular have a look daemon(7),
i.e. http://0pointer.de/public/systemd-man/daemon.html and related man
pages. A good example for a systemd-enabled RPM for a D-Bus service is
rtkit. You might want to check it out and its .spec file:
http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?view=markup
A good example for a systemd-enabled RPM for a service that currently
installs a SysV init script, checkout Avahi and its .spec file:
http://cvs.fedoraproject.org/viewvc/devel/avahi/avahi.spec?view=markup
Some package could use the native unit love more than others. For
example, I have seen terrible things done to daemonize
processes and drop privs in pure shell (the bittorrent packages as one
example). Packages like that could really benefit from native unit
files which make this much easier and nicer and cleaner.
c) if you are the developer of a package that could benefit from socket
activation, please consider patching it for it. How that works is
documented in the man pages:
http://0pointer.de/public/systemd-man/daemon.html and
http://0pointer.de/public/systemd-man/sd-daemon.html and related, see
http://0pointer.de/public/systemd-man/ for the full list.
d) There's one thing that is not directly related to systemd but which
I'd really like to see done at the same time: moving /var/lock and
/var/run to tmpfs, like suse and ubuntu already did it. The changes
necessary should be small, but probably in a non-trivial number of
packages: each mention of /var/run in the .spec files needs to be
%ghosted. Also, some minimal changes to rc.sysinit need to be done, so
that the dirs are mounted (this could be done by systemd too, in case we
get the sysinit split hhoyer started to work on done before
F14). Finally, there might be a few packages which start to act confused
if their directories beneath /var/run is go away on reboot. But these
problems should already have been fixed by the Ubuntuans and Suses of
this world for us. It would be really great if somebody would volunteer
for this and go through the packages to add %ghost everywhere and ensure
otherwise this works out. The ubuntu and suse folks might have some
docs around with more ideas about this.
e) play around with systemd, test it!
f) contribute to our work! We always are happy about people contributing
code or docs, or even artwork (we could use a logo... ;-)).
And again, if anybody has a question, many systemd folks are around on
#systemd on fdo, and particularly me, mezcalero. So if you have
questions, ask us there, or right here on this thread.
There are a couple of bugs that still need to be fixed in other
packages than systemd, before F14:
https://bugzilla.redhat.com/show_bug.cgi?id=614245
https://bugzilla.redhat.com/show_bug.cgi?id=612789
https://bugzilla.redhat.com/show_bug.cgi?id=612728
https://bugzilla.redhat.com/show_bug.cgi?id=612712
That said, things should already work really well in rawhide right now,
and you should have no trouble bringing up and down the system with
systemd using its sysv compatibility logic to execute the existing SysV
init scripts. Please try it out and report back. Note that you still
need to pass "init=/bin/systemd" on the kernel command line, until the
point I make the change i mentioned above.
A short FAQ:
1) Q: If I patch my service for systemd socket activation, will this break
things for people not using systemd?
A: No, it won't.
2) Q: If I ship native systemd unit files, will this break things for
people not using systemd?
A: No, it won't.
3) Q: Will things become miraculously fast by booting with systemd?
A: No, it won't. When you boot with only SysV services
(i.e. utilizing the systemd SysV compatiblity logic to its max),
things should become only very little faster, as only very minimal
parallelization is employed then. And even if you have added native
service files for every single service, you won't make a slow
machine a supercomputer. Speeding up the boot requires a lot of
work everyhwere, and it is not sufficient to parallelize only
daemon bootup. i.e. rc.sysinit needs more parallelization too, and
is currently a single linear monolithic script. That said, on SSD
things should be noticably faster (though don't expect too much),
on rotating media things are not as rosy, simply because the Linux
IO scheduler cannot fully
keep up with with the increased parallelization and readahead is not a
solution for this, but more of a kinda futile attempt to fix this
without touching the kernel. Stuff like Jens Axboe's fcache sound
like a better solution, and even a bit like the approaches MS and
Apple took in this area.
Let me stress here however that I would like to see people judge
systemd not by its mere speed. Please see the full set of features
(again, read the initial blog post for details and maybe even the
man pages). It is our main objective to do things right. One part
of "doing it right" is "doing it fast", but it's far from
the only
thing.
4) Q: If I don't care about systemd and don't update my packages, will
things stop working for me in F14?
A: No, they will continue to work. Since systemd's SysV compatiblity is quite
extensive things should just continue to work just fine.
5) Q: Why systemd? Isn't Upstart awesome too?
A: Well, opinions on that matter, see my original blog story for
details. Suffice to say that I am not exactly the only one who
thinks this way.
6) Q: LSB/SysV init scripts are standardized in the LSB! Why are you
breaking with that standard?
A: Well, actually we aren't. systemd provides compatibility with SysV
to a very large degree, we even have support for various
distribution extensions. The vast majority of init scripts should
continue to work in systemd just fine, even though they might work
even better with native unit files.
In the long run we actually hope to minimize differences between
distros with this, by establishing common hooks services should
use and asking everybody to use those hooks and ship their service
files in their upstream packages. The idea is that the systemd
unit file is automatically a lot more portable and
distribution-independent then the init scripts ever were.
7) Q: Are the other distros switching too?
A: Well, they are not as fast, but it looks very much like it. I have
been working very closely with Kay Sievers from Suse to integrate
systemd equally well into the OpenSuse semantics, and it will
enter their distro as soon as their development cycle
reopens. Debian, Gentoo, ArchLinux have packages in their
archives, but it's not the default there (yet?). I guess at least
for Debian/Gentoo it is very hard to make decisions about dfaults
like this. Meego has someone working on this, but I have
not followed that closely. And there are some smaller distros
which have adopted it too, and I know at least one (Pardus) that
plans to make it the default in the next release. And regarding
Ubuntu I leave it to you figuring out what is going on (Hint: you
might want to check out for what company the main developer of
Upstart -- which systemd replaces -- works for...). And never
forget that Fedora is of course the leader in development, so it
should be us who lead here... ;-)
And if you have any further questions, talk to us on IRC! Or reply to
this thread!
And also, don't forget to check the (extensive I believe) body of
documentation we now have, it might already answer your question. In
particular the blog story I already mentioned way too often:
http://0pointer.de/blog/projects/systemd.html
It's quite a novel I fear, but full of interesting stuff. And then there is the set of
man pages:
http://0pointer.de/public/systemd-man/
Lennart
--
Lennart Poettering - Red Hat, Inc.