systemd System and Session Manager
systemd is a replacement for SysVinit that acts as a system and session manager.
- Name: Lennart Poettering ; Rahul Sundaram
- Email: lpoetter AT redhat DOT com ; sundaram AT fedoraproject.org
- Targeted release: Fedora 14
- Last updated: 2010-07-14
- Percentage of completion: 50%
- Systemd is currently in Rawhide, but not the default yet (i.e. It currently conflicts upstart, but it should obsolete it). However it can boot rawhide systems fine via the SysV compatibility support.
- Patches for various packages have been merged upstream and already found there way into Rawhide (dbus, udev, avahi, rtkit). Socket activation support that would be nice to have is still missing for rsyslog (submitted upstream, no comment yet), rpcbind (submitted upstream, partly merged), cups (not submitted yet).
- What is systemd? To quote the homepage: "systemd is a system and session manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit."
- The plan is to test it thoroughly and make it the default for Fedora 14, replacing the current default, upstart. The more daemons we can update to ship native service files the better. The remaining software can continue to include the sysv init scripts and systemd is compatible with them.
- Instead of bash scripts, systemd uses dot service files
- systemd sorts all daemons into their own Linux cgroups, which you may explore beneath /cgroup/systemd in the file system hierarchy.
- systemd's focus is about making the best of Linux and using its features as well as possible. systemd is not intended to be portable. This opens up numerous new possibilities.
Benefit to Fedora
Fedora currently uses Upstart but in SysV compatibility mode. systemd is a overall better design as detailed in http://0pointer.de/blog/projects/systemd.html. We hope to reap the benefits of it by leading in distribution integration and including it by default.
Note that in the long run systemd will provide quicker boot up, but completing that will take more work, since some additional changes to our early boot-up need to take place such as splitting up rc.sysinit. However the focus of systemd is primarily doing things right, and not exclusively on speed.
Requires building packages for systemd (DONE: https://bugzilla.redhat.com/show_bug.cgi?id=598299 ), and taking advantage of it in a dozen or so desktop daemons that will benefit from systemd the most at present and make it default for Fedora 14.
Requires Packaging Guidelines telling us how to use systemd unit files and whether to require both SysVinit and systemd scripts or only one of those. At present, I'm under the assumption that we will require SysVInit scripts for F14 an have systemd script unit files optional; for F15 or above, we'll look at changing those. We need to have the guidelines for writing systemd unit files and systemd spec file scriptlets first, though, if this is going to be the default and we're not going to strongly discourage the use of unit files (as we do with upstart events).
- Boot the system, make sure all services come up.
- Shutdown and ensure that everything is shut down properly.
- Check the various admin tools such as systemctl, systemd-install, systemd-cgls, systemadm, ps and so on.
- Verify that all services are properly put in seperate control groups (systemd-cgls is your friend)
- Verify that "systemctl list-units" shows that all units are in a reasonable state after bootup. (i.e. no red color in the output!)
- Play around with "systemd.unit=emergency.target", "systemd.unit=rescue.target", "systemd.unit=multi-user.target" and suchlike on the kernel command like and switching between the targets via "systemctl isolate".
- Try the following kernel command line options:
- systemd.unit=emergency.target (which gives you something very similar to passing init=/bin/sh but with the option to boot the full system from there)
- systemd.unit=rescue.target (similar, but is mostly equivalent to booting into single user mode on sysv)
- systemd.unit=multi-user.target (to boot only non-graphical stuff)
- systemd.unit=graphical.target (to boot the normal graphical stuff, the default)
The user should notice a slightly faster bootup, particularly on SSD.
The administrative features of the init system are considerably extended. (for more details see the aforementioned blog post, in particular the "A short list of other features:" part.
Native systemd service configuration files are much easier to understand and configure compared to sysvinit scripts
- Successful Fedora Package review and addition to rawhide: DONE
- systemd upstream currently lacks three features that we need before Fedora 14:
- proper support for selinux (needs policy changes, and we want to move the policy setup in systemd, not in the initrd). DONE: Latest selinux policy update include changes for systemd.
- We need sysv compatible implementations for /bin/reboot, /bin/shutdown and friends. We currently simply use the implementations upstart provides which work fine, but of course are suboptimal as soon as we want to replace upstart completely. DONE
- complete set of man pages (parts are already documented, this is far from complete however). DONE
- The readahead packages need to be adapted for systemd. readahead is currently one of the very few packages using upstart specific features and hence is not activated when booting with systemd. However, due to the more aggressive parallelization, disk access is much more random when systemd is used and hence the effect of readahead considerable. Or to put it the other way round: unless we have readahead systemd won't perform any better than upstart/sysv during bootup on rotating media. On SSD systemd is considerably faster though in every case as readahead is not necessary there.
- A number of daemons should provide native systemd .service files in addition to sysv init scripts. I have service files for almost all standard F13 services ready, which just need to be added to the rpms.
- A number of daemons should be patched for socket activation: rsyslog (PENDING), dbus (DONE), portmap (PENDING), avahi (DONE), nscd, cups. These patches exist (and are public) and should have upstreamable quality, but they need to be reviewed and added to the rpms.
- A number of daemons should ship changed bus activation files to hook them up to systemd for activation (single-line change per package)
- Some (small) bugs in other packages need to be fixed: 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
- Revert back to ship the current Upstart package, and offer systemd just as an alternative.
- Reverting back does not mean that any of the changes in other packages need to be rolled back. Native systemd unit files are simply ignore by other init systems, and the socket actviation patches and suchlike disable themselves automatically if systemd is not used, and become NOPs. Rolling back is hence nothing more than making upstart obsolete systemd in rawhide.
- We are aware that trying to pull this off so quickly after the initial announcement of systemd is ambitious. However, we believe we can do this. When this is accepted by FESCO we should define a date where we reinvestigate the whole issue and should it turn out that systemd adoption as default did not work out as we intended by that date we will make upstart default again and offer systemd only as a alternatively installable option.
- The package comes with a full set of man pages. http://0pointer.de/public/systemd-man/
- Project homepage has more details at http://www.freedesktop.org/wiki/Software/systemd
Fedora 14 has replaced Upstart with systemd. systemd uses services files located in /lib/systemd/system for services, and /etc/systemd/system for configuration. A dozen desktop daemons [list them] have been initially converted to use systemd service files and small number of programs have been patched to take advantage of it. systemd is compatible with legacy SysV init scripts and rest of the migration will happen incrementally over time.