All notes



When run as a system instance, systemd interprets the configuration file /etc/systemd/system.conf and the files in /etc/systemd/system.conf.d directories; when run as a user instance, systemd interprets the configuration file user.conf and the files in user.conf.d directories. These configuration files contain a few settings controlling basic manager operations.

systemd vs SysV or Upstart

Comparison by commands:

# Starts a service.
service name start
systemctl start name.service

# Stops a service.
service name stop
systemctl stop name.service

# Restarts a service.
service name restart
systemctl restart name.service

# Restarts a service only if it is running.
service name condrestart
systemctl try-restart name.service

# Reloads configuration.
service name reload
systemctl reload name.service

# Checks if a service is running.
service name status
systemctl status name.service
systemctl is-active name.service

# Displays the status of all services.
service --status-all
systemctl list-units --type service --all
# Comparison of the chkconfig Utility with systemctl

# Enables a service.
chkconfig name on
systemctl enable name.service
systemctl reenable name.service

# Disables a service.
chkconfig name off
systemctl disable name.service

# Checks if a service is enabled.
chkconfig --list name
systemctl status name.service
systemctl is-enabled name.service

# Lists all services and checks if they are enabled.
chkconfig --list
systemctl list-unit-files --type service

# Lists services that are ordered to start before the specified unit.
chkconfig --list
systemctl list-dependencies --after

systemctl list-dependencies

# Lists services that are ordered to start after the specified unit. 
chkconfig --list
systemctl list-dependencies --before

# List known units
systemctl [list-units]
systemctl --all
# List failed units:
systemctl --failed

# Lists currently loaded target units:
# Same as "runlevel" command in SysV
systemctl list-units --type target

systemctl list-units --type service

# Show all installed unit files
systemctl list-unit-files

# Determine which target unit is used by default
systemctl get-default
# In arch, it's

# Replace name with the name of the target unit you want to use by default (for example, multi-user). This command replaces the /etc/systemd/system/ file with a symbolic link to /usr/lib/systemd/system/
systemctl set-default

# This command is similar to "systemctl isolate", but it also sends an informative message to all users that are currently logged into the system.
systemctl rescue

# Change to a different target unit in the current session:
# Seme as "telinit runlevel" in SysV
systemctl isolate

systemctl start/stop/restart/reload/status
systemctl is-enabled/enable/disable unit

# Mask a unit to make it impossible to start it:
systemctl mask unit
systemctl unmask unit

# Show the manual page associated with a unit (this has to be supported by the unit file):
systemctl help unit

systemctl daemon-reload

systemctl reboot/poweroff/suspend/hibernate

Symbolic unit file is not followed by design


# Use this to debug.
# wcf.serve is a symbolic pointing to /home/wcf/conf/wcf.service.
cd /etc/systemd/system
strace -o trace.txt systemctl enable wcf.service

# The result is:
# open("///etc/systemd/system/wcf.service", O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of symbolic links)

# O_NOFOLLOW implies that it won't be followed.

The solution is to enable directly on the real file: systemctl enable /home/wcf/conf/wcf.service. The following is the explanation:

"systemctl enable" is about enabling vendor supplied unit files. It will only create and remove symlinks in /etc/ and /run/, that's all it does. So right now it's a pretty safe tool: it will create/override/remove the modifiable configuration via symlinks and strictly leave vendor supplied static data untouched, since it is stored in real files. However, if we suddenly allow enabling of symlinks, then this clear separation goes away.

This gets particularly nasty for disabling things, because that removes all symlinks to the destination file, and how should it know when to stop precisely?

So, yeah, I am pretty sure we shouldn't allow "enabling of symlinks".

What we should support however is enabling of unit files that are outside of the usualy search paths, via specifiying full absolute paths. i.e. "systemctl enable /var/lib/foo/bar.service" should link it to /etc/systemd/system/bar.service and do everything listed in [Install]. Now, I originally implemented things to work like that, but this might got broken one time...

Andrew, so if you'd call "systemctl enable" directly on the original unit file, instead of via a symlink, then everything should be fine for you, right?



Can't sudo in user services

After typing

systemctl --user start wcf

# To see the log:
systemctl --user status wcf
# or use:
journalctl --user-unit wcf

It says:

Jul 15 23:04:30 wcfThinkpad systemd[498]: Started wcfStartUp.
Jul 15 23:04:30 wcfThinkpad systemd[498]: Starting wcfStartUp...
Jul 15 23:04:30 wcfThinkpad[1831]: sudo: no tty present and no askpass program specified
Jul 15 23:04:30 wcfThinkpad sudo[1837]: pam_unix(sudo:auth): auth could not identify password for [wangcf]


systemd uses targets which serve a similar purpose as runlevels but act a little different. Each target is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some targets are implemented by inheriting all of the services of another target and adding additional services to it. There are systemd targets that mimic the common SystemVinit runlevels so you can still switch targets using the familiar telinit RUNLEVEL command.




#---------- Manager Lifecycle Commands

# Reload systemd manager configuration. This will rerun all generators (see systemd.generator(7)), reload all unit files, and recreate the entire dependency tree.
systemctl daemon-reload

# List all failed
systemctl --failed
# After fixing all the failed, reset and see
systemctl reset-failed

#---------- Remove

# E.g. remove the samba, which is replaced by smbd.service.
systemctl stop [servicename]
systemctl disable [servicename]
# Check the symbolic file is removed:
# /etc/systemd/system/[servicename]
# systemctl daemon-reload
systemctl reset-failed

systemd.generator (binaries that live in /usr/lib/systemd/user-generators/) is used to convert configuration files that are not native unit files dynamically into native unit files.

Unit files


The syntax of systemd's unit files is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files.


man systemd.unit

# View the content of a unit file and all associated drop-in snippets.
systemctl cat nginx

# Analyze each service for startup time cost
# suse.
systemctl-analyze blame

systemd-analyze plot

#---------- Reload
# Edit the unit (and reloads the unit automatically)
systemctl edit

# reload all units with:
systemctl daemon-reload

#---------- Replacement unit files
# To replace the unit file /usr/lib/systemd/system/"unit", create the file /etc/systemd/system/"unit" and reenable the "unit" to update the symlinks:
systemctl reenable unit

# Alternatively, run:
systemctl edit --full "unit"
# e.g.: systemctl edit --full nginx

# The replacement units will keep on being used even if Pacman updates the original units in the future. This method makes system maintenance more difficult and therefore the next approach ("drop-in files") is preferred.

#---------- Drop-in files
# Opens the file /etc/systemd/system/unit.d/override.conf in your text editor (creating it if necessary) and automatically reloads the unit when you are done editing:
systemctl edit unit

# Revert to vendor version
systemctl revert unit

# See which unit files have been overridden or extended and what exactly has been changed:


Units can be, for example, services (.service), mount points (.mount), devices (.device) or sockets (.socket).

Unit files are loaded from two locations. From lowest to highest precedence they are:

  1. /usr/lib/systemd/system/: units provided by installed packages
  2. /etc/systemd/system/: units installed by the system administrator

If the unit A requires the unit B to be running before A is started. In that case add Requires=B and After=B to the [Unit] section of A. If the dependency is optional, add Wants=B and After=B instead.
Note that Wants= and Requires= do not imply After=, meaning that if After= is not specified, the two units will be started in parallel.

Dependencies are typically placed on services and not on targets. For example, is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since is started anyway.

Service types

This is set with the Type= parameter in the [Service] section:

See man systemd.service for a more detailed explanation.

rc.local support on Arch Linux with systemd

Raymii. Arch Linux uses systemd. Therefore, init functions like rc.local are not supported anymore.


// Edit /usr/lib/systemd/system/rc-local.service:
Edit $HOME/conf/rc-local.service:

Description=/etc/rc.local compatibility

# Executable path must be absolute: /bin/bash.
# If you omit /bin/bash, then /etc/rc.local must be executable by all.
ExecStart=/bin/bash /etc/rc.local


Enable it:

# systemctl enable rc-local.service
# rc-local.service will be sym-linked to /etc/systemd/system/
systemctl enable ${HOME}/conf/rc-local.service

systemctl restart rc-local
systemctl status rc-local

systemctl list-unit-files|grep rc-local


Unit service failed to load: No such file or directory

StackExchange. All services need to be loaded and parsed before starting them, and your service isn't available early on in the boot process when systemd parses all services since it's on a different partition.

To solve it either keep the local services in /etc/systemd/system/ or make a package for your distribution and place them in /usr/lib/systemd/system/.

Could not insert 'vboxsf': No such device

If your ArchLinux is installed as host, then virtualbox-guest-* are not needed.

# Check if virtualbox-guest-* are installed.
pacman -Qs virtualbox

# Remove all guest installations.
sudo pacman -Rss virtualbox-guest-utils
sudo pacman -Rss virtualbox-guest-dkms
# Don't remove virtualbox-guest-iso.

archWiki: virtualbox. VirtualBox Guest Additions provides drivers and applications that optimize the guest operating system including improved image resolution and better control of the mouse. Install them within the installed guest system.

There is one exception. It is recommended to install the virtualbox-guest-iso package on the host running VirtualBox. This package will act as a disc image that can be used to install the guest additions onto guest systems other than Arch Linux.


# -0 is the last boot, which is default, -1 the boot before last.
journalctl -b | grep rc-local

# -r, --reverse
# -a, --all: Show all fields in full
# -x, --catalog: Augment log lines with explanation texts from the message catalog.

# -e, --pager-end: Immediately jump to the end of the journal
# -n, --lines= : Show the most recent journal events and limit the number of events shown. If --follow is used, this option is implied. The argument, a positive integer, is optional, and defaults to 10.

# -p, --priority=num: "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6), "debug" (7)
# -b [ID][±offset], --boot=[ID][±offset]: Show messages from a specific boot. This will add a match for "_BOOT_ID=". The argument may be empty, in which case logs for the current boot will be shown.

journalctl -p 3 -xb
journalctl -p 0..4 -r

journalctl -xen

Show log for user services

StackExchange. Use the following commands to see the user services' log:

# -f, --follow
journalctl -f
# or better,
journalctl --user-unit serviceName