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.
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
# systemctl start mpd
To have a service always start on system boot use the
enable command (the inverse is
# 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 (without -n journalctl 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 of the last boot:
$ journalctl -b
Optionally you can again include the -e option to skip right to the end.
Units are the basic mode of interaction with systemd. There are several types of units for different types of tasks. Mostly you will interact with the .service type of unit, which executes 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 Journal is the log of systemd. The basic command to interact with this functionality is
The type of a systemd unit is indicated by the extension of its file. E.g. a Service unit file will be named
name.service and a Path unit file will be named
.service may be omitted when using units e.g. on the command line. When you say
systemctl enable mpd it will be assumed you mean
systemctl enable mpd.service. But you cannot omit the extension in, say,
systemctl enable check-changed.path.
|Service||Basic unit type. Starts a program, daemon, script, etc.|
|Target||Dependency "checkpoint". Targets pull in other units to form a predefined state.|
|(Auto)Mount||Mounts a filesystem, normally or on request (Automount).|
|Timer||Similar to cron jobs. Execute a corresponding unit at a set time, date or interval.|
|Device||systemd wrapper for udev devices, managed by systemd.|
|Path||Watches a path and activates a corresponding unit depending on changes.|
|Socket||Activates a unit on a request to its socket. On-demand service activation.|
|Slice||Used for hierarchical resource management of units. Other units may be assigned to a slice.|
|Swap||Swap space controlled by systemd.|
Limiting resources for a unit
Watching a path
Common systemctl commands
||start <unit> now|
||stop <unit> now|
||enable <unit> to run on boot|
||disable <unit> running at boot|
||unlink and relink <unit> to wants|
||stop and start <unit>|
||query information, status and log of <unit>|
||reload unit definitions from their files|
||view elaborate properties of <unit>|
||view the content of <unit>'s unit file|
man systemctlfor a complete list