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?



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

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]

Unit files

man systemd.unit
systemctl cat unit.service

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

systemd-analyze plot

Service types

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

See man systemd.service for a more detailed explanation.


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.



Check for errors

systemctl --failed

# -p, --priority=num
# "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6), "debug" (7)
# -x, --catalog
# Augment log lines with explanation texts from the message catalog.
# -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

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

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

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

# -a, --all: Show all fields in full

# -x, --catelog: Augment log lines with explanation texts from the message catalog.
# -e, --pager-end: Immediately jump to the end of the journal
journalctl -xe