systemd is a system and service 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.
- 1 Minimal install
- 2 Using systemd
- 3 Arch integration
- 4 Helping out
- 5 FAQ
- 5.1 My console fonts are ugly
- 5.2 My dmesg is full of syslog messages
- 5.3 How do I boot into a different "runlevel"?
- 5.4 How do I make a custom unit file?
- 5.5 How do I enable/disable some getty's?
- 5.6 How do I get more verbose output during boot?
- 5.7 What kernel options do I need to enable in my kernel in case I don't use the official Arch kernel?
- 6 Optimization
To try out systemd on Arch you need to
- install initscripts-systemd-git (and it's dependencies),
- append init=/bin/systemd to the end of your kernel line in GRUB.
Note that systemd can be installed side-by-side with the regular Arch initscripts, and they can be toggled by adding/removing the init=/bin/systemd kernel parameter.
Dependencies from AUR
To take advantage of the systemd way of starting services, you might also want the systemd-arch-units package.
The available services or units can be seen in /lib/systemd/system and /etc/systemd/system (the latter takes precedence).
To start/stop/restart a service use:
$ systemctl start|stop|restart <service>
To automatically start a service on boot use:
$ systemctl enable <service>
Notice that you need to use the full name of a service file. E.g., in order to restart the avahi daemon, issue:
$ systemctl restart avahi-daemon.service
/etc/inittab is not read by systemd, but the standard systemd setup matches the standard inittab setup. To customise it, please see FAQ.
/etc/rc.local and /etc/rc.local.shutdown are run at boot/shutdown as before. To disable this do 'systemctl disable rc-local.service'.
Most of /etc/rc.conf is respected by systemd. For a pure systemd setup it is recommended to use the native systemd configuration files which will take precedence over /etc/rc.conf.
- HOSTNAME (this and all above is parsed at boot-time, the native systemd configuration takes presedence)
- TIMEZONE (set at shutdown)
- MODULES (blacklisting is respected)
- DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-damens.target')
- HARDWARECLOCK (TODO: look into how this works)
- USELVM (use 'systemctl enable|disable lvm-activate.service' instead)
Currently, systemd is mostly at feature parity with Arch's initscripts. However, a lot more testing is needed. If you'd like to help out, you can fork the initscripts-systemd or arch-systemd-units git repos and submit pull requests for your additions.
If you have any questions, ask in the thread in the Arch forums. falconindy is also somewhat available on IRC in #archlinux (please, no private messages).
My console fonts are ugly
Yes. If no font is set in /etc/vconsole.conf (or alternatively /etc/rc.conf), then a standard font will be used. Set your preferred font to fix the issue.
My dmesg is full of syslog messages
Syslog is one of the few daemons (together with dbus and udev) that need special systemd support. syslog-ng does not yet have this support, so all messages are duplicated in dmesg and /var/log/*. The development version of rsyslog has systemd support, and patches are being prepared for the other common syslog implementations.
How do I boot into a different "runlevel"?
The standard target (which is what runlevels are called in a systemd world) is graphical.target (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following kernel parameters to your GRUB kernel line:
- systemd.unit=multi-user.target (which roughly corresponds to the old runlevel 3),
- systemd.unit=rescue.target (which roughly corresponds to the old runlevel 1).
How do I make a custom unit file?
The unit files in /etc/systemd/system take precedence over the ones in /lib/systemd/system. To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from /lib to /etc and make your changes there.
How do I enable/disable some getty's?
To enable more or fewer getty's than the standard six, add or remove symlinks to the /etc/systemd/system/getty.target.wants folder. E.g.:
$ ln -s /lib/systemd/system/getty\@.service /etc/systemd/system/getty.target.wants/getty\@tty10.service
gives you a getty on tty10.
How do I get more verbose output during boot?
By default systemd does not give much (if any) output during boot. Firstly, lots of output from services running in parallel would be very messy, and secondly, boot is supposed to be so fast that status messages would slow it down.
If you append the kernel parameter "verbose" to your kernel line in GRUB, you will get lots of output during boot. However, this is only really meant as a debugging tool as it is not very useful during normal use. Any messages are logged to the system log and if you want to find out about the status of your system
is your friend.
What kernel options do I need to enable in my kernel in case I don't use the official Arch kernel?
This is a partial list of required/recommended options, there might be more:
CONFIG_DEVTMPFS=y CONFIG_CGROUPS=y CONFIG_AUTOFS4_FS=[y|m] CONFIG_IPV6=[y|m], optional, but highly recommended CONFIG_RTC_DRV_CMOS=y, optional, but highly recommended CONFIG_FANOTIFY=y, optional, required for systemd readahed. Availabe in Linux kernel >= 2.6.37-rcX.
One central feature of systemd is dbus and socket activation, this causes services to be started when they are first accessed, and is generally a good thing. However, if you know that a service (like console-kit) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be acheived (if the service file is set up for it, which in most cases it is) by issuing:
$ systemctl enable console-kit-daemon.service
This will cause systemd to start console-kit as soon as possible, without causing races with the socket or dbus activation.
The default setup will fsck and mount all filesystems before starting most daemons and services. If you have a large /home partition, it might be better to allow services that do not depend on /home to start while /home is being fsck'ed. This can be acheived by adding the following options to the fstab entry of your /home partition
This will fsck and mount /home when it is first accessed, and the kernel will buffer all file access to /home until it is ready.
systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and your the type of your hard drive, your milage might vary (i.e. it might make boot slower). To enable do:
$ systemctl enable systemd-readahead-collect.service $ systemctl enable systemd-readahead-replay.service
Remember that in order for the readahead to work its magic you should reboot a couple of times.