From ArchWiki
Revision as of 15:08, 24 March 2011 by Cedeel (talk | contribs) (How do I change my default target permanently?: -f flag needed to overwrite symlink)
Jump to: navigation, search

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.

See Lennart's blog story for a longer introduction, and the two status updates since then. Also see the Wikipedia article and the project web page.


To try out systemd on Arch you need to

  • install initscripts-systemd (and its dependencies) from community
  • 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.

  • To take advantage of the systemd way of starting services, you might also want the systemd-arch-units package.

Using systemd

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

Running DEs under systemd

To enable graphical login run your preferred Display Manager daemon (e.g. KDM):

# systemctl enable kdm.service

Arch integration

/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')

Not supported

  • HARDWARECLOCK (use 'hwclock --systohc --utc' to set your hardware clock to utc, localtime is not supported, see FAQ)
  • USELVM (use 'systemctl enable|disable lvm-activate.service' instead)

The initscripts-systemd package

This package contains unit files and scripts that are needed to emulate Arch's initscripts. Most people will not need all (if any) of these units, and they can be easily disabled by doing

# systemctl disable <unitfile>

if you determine that you don't want a particular unit.

The plan is to remove most of the functionality from this package as soon as it is handled elsewhere (mostly in udev/systemd/kernel).

The following is a brief description of the functionality of each of them.


Sets your domainname. This is deprecated, and should probably not be used.


Runs /bin/depmod on boot. It is probably sufficient to do this as part of the kernel install, but this needs to be verified.


Copies Arch's handling of LVM. Only needed if you use non-root LVM. In the future systemd will probably deal with this natively (in a much cleaner and more robust way).


Copies Arch's handling of RAID. Only needed if you use non-root RAID. In the future systemd will probably deal with this natively (in a much cleaner and more robust way).


Runs /etc/rc-local (resp., /etc/rc-local.shutdown) on boot (resp., shutdown).

Parses the DAEMONS array in rc.conf and starts the services. If a native systemd unit exists (by the same name) for a given daemon, this is used, otherwise the script in /etc/rc.d/ is used to control the unit.


This is run at shutdown, it's aim is to make sure that any Arch settings is applied on next boot. In particular:

  • it sets the timezone based on rc.conf
  • it saves persistent udev rules (net and cd)
  • it blacklists modules based on rc.conf (see /etc/modprobe.d/rc.conf)
  • it creates a list of modules to be loaded based on rc.conf (see /etc/modules-load.d/rc.conf)

Helping out

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 systemd-arch-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).


For an up-to-date list of known issues, look at the upstream TODO.

Why are my console fonts ugly?

If no font is set in /etc/vconsole.conf (or alternatively /etc/rc.conf), then a standard font will be used. The standard font is chosen due to it supporting a wide range of character sets. Set your preferred font to fix the issue.

Why is my dmesg full of syslog messages

Syslog is one of the few daemons (together with dbus and udev) that need to be patched to work well with systemd. syslog-ng does not yet have this support, so all messages are duplicated in dmesg and /var/log/*. The required support is now in the git branch that will become syslog-ng 3.2.3. The development version of rsyslog also has systemd support.

Why do I get log messages on my console?

See the previous question. Depending on your log target and level, you might also get some syslog messages on your console. This will be fixed once we have rsyslog or syslog-ng with systemd support.

Why are there duplicates in the output of df/mount?

Systemd expects /etc/mtab to be a symlink to /proc/self/mounts. This is going to be the recommended setup by upstream (util-linux) in the near future, but for the time being there are still some regressions related to fuse. For that reason we leave /etc/mtab as it is until the last kinks have been worked out upstream. You can manually create the symlink if you think you are not affected by the regressions.

Why does systemd not support the RTC being in localtime?

In principle, there is nothing stopping you from adding some unit files that will allow the RTC to be in localtime, but there are a few reasons why we have not (and probably will not) implement it by default:

  • The reason for allowing the RTC to be in localtime was to allow dualboot with Windows (who uses localtime). However, for some time now, Windows has been able to deal with the RTC being in UTC by setting the following registry key

This needs to be a DWORD key with a value of 1.

  • Dealing with daylight saving time is messy. If the DST changes when your computer is off, your clock will be wrong on next boot (there is a lot more too it).
  • Recent kernels set the system time from the RTC directly on boot without using 'hwclock', the kernel will always assume that the RTC is in UTC. This means that if the RTC is in localtime, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. It is not clear that this will not introduce weird bugs (time going backwards is rarely a good thing).

How do I boot into a different "runlevel"?

The standard target (which is what runlevels are called in a systemd world) is (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:

  • (which roughly corresponds to the old runlevel 3),
  • (which roughly corresponds to the old runlevel 1).

How do I change my default target permanently?

Make a symlink from /etc/systemd/system/ to your desired target. To change to do:

ln -sf /lib/systemd/system/multi-user.targt /etc/systemd/system/

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/ folder. E.g.:

# ln -s /lib/systemd/system/getty\@.service /etc/systemd/system/\@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

$ systemctl

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_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.


Less output

Change 'verbose' to 'quiet' on the kernel line in GRUB. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.

Early start

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.