From ArchWiki
< User:Grandchild
Revision as of 16:34, 7 September 2014 by Grandchild (talk | contribs) (Journal)
Jump to navigation Jump to search

From the project web page:

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 control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.
Note: For a detailed explanation as to why Arch has moved to systemd, see this forum post.


systemd is installed by default on any new Arch installation since late 2012. It replaced SysVinit which is now deprecated.

Getting started


To list the state of all the currently enabled units on the system simply run

$ systemctl

  UNIT                            LOAD   ACTIVE SUB       DESCRIPTION
  dhcpcd.service                  loaded active running   dhcpcd on all interfaces
  systemd-modules-load.service    loaded active exited    Load Kernel Modules
● shadow.service                  loaded failed failed    Verify integrity of password and group files

To start a service, for example mpd, use the start command (the inverse is stop):

# systemctl start mpd

To have a service always start on system boot use the enable command (the inverse is disable):

# systemctl enable mpd

On success this command will output information on linking the unit file to the wanted units. No output indicates something went wrong (or often that the unit was already enabled).

To investigate a unit's status, like shadow.service which is marked as failed above, run

$ systemctl status shadow.service

This will print out some general information about the unit and the last few journal/log messages - if there are any - which will help you find out why a unit has failed to start.


To view the last 100 lines of the system log run

$ journalctl -e -n 100

The -e option makes the output skip to the end, and the -n option sets the number of lines to display (-n defaults to 1000, and larger values will take a few seconds to display)

To follow the journal as it gets written leave the following running in a terminal

$ journalctl -f

To diagnose your boot process have a look at just the logs pertaining to booting the system and run

$ journalctl -b

Optionally you can again include the -e option to skip right to the end. The -x option will give supposedly helpful explanations on a few entries although these will mostly clutter up your log with verbose unit startup details.


The basic mode of interaction with systemd is via Units. There are several types of units for different types of tasks. Mostly you will interact with the .service type of unit, which execute daemons and other scripts and programs. There are also .mounts, .devices, .timers, .paths and others. See Units for a detailed description of the various types and tasks.

The logs of systemd are Journals. The basic command to interact with this functionality is journalctl



Unit Files

Advanced Tasks


Limiting resources for a unit

Watching a path

Using slices

Using targets


Common systemctl commands

Command Task
systemctl start [unit] start [unit] now
systemctl stop [unit] stop [unit] now
systemctl enable [unit] enable [unit] to run on boot
systemctl disable [unit] disable [unit] running at boot
systemctl reenable [unit] unlink and relink [unit] to wants
systemctl restart [unit] stop and start [unit]
systemctl status [unit] query information, status and log of [unit]
systemctl daemon-reload reload unit definitions from their files
systemctl show [unit] view elaborate properties of [unit]
systemctl cat [unit] view the content of [unit]'s unit file
Note: See man systemctl for a complete list