All notes
Systemd

# Basics

• systemd is the default init framework, replacing initscripts.
• The services which are started by systemd can be found in the subfolders of /etc/systemd/system/.
• Services can be enabled using the systemctl command.
• Units can be, for example, services (.service), mount points (.mount), devices (.device) or sockets (.socket).
• If you do not specify the suffix, systemctl will assume .service.
• Mount points will automatically be translated into the appropriate .mount unit. For example, specifying /home is equivalent to home.mount.
• Similar to mount points, devices are automatically translated into the appropriate .device unit, therefore specifying /dev/sda2 is equivalent to dev-sda2.device.

## Conf

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

• The init scripts in /etc/rc.d/init.d/ have been replaced with service units with the .service file extension.

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

# 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 graphical.target

# 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 graphical.target

# 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/default.target file with a symbolic link to /usr/lib/systemd/system/name.target
systemctl set-default name.target

# This command is similar to "systemctl isolate rescue.target", 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 name.target

systemctl is-enabled/enable/disable unit

# Mask a unit to make it impossible to start it:

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

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?


## Systemd-User

• Enabling users to start, stop, enable, and disable their own units.
• On the first login of a user, systemd automatically launches a systemd --user instance, responsible to manage user services.
• By default no user services are run.
• User units are located in the following directories just as they would with system services (ordered by ascending precedence):
1. /usr/lib/systemd/user/, where services provided by installed packages go.
2. /etc/systemd/user/, where system-wide user services are placed by the system administrator.
3. ~/.config/systemd/user/, where the user puts its own services.
• To check that it is already running you can use systemctl --user status serviceName.
• All the user services will be placed in ~/.config/systemd/user. If you want to run services on first login, execute systemctl --user enable serviceName for any service you want to be autostarted.

#### 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 init.sh[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

• Units can be, for example, services (.service), mount points (.mount), devices (.device) or sockets (.socket).
• 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.
• 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, network.target is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since network.target is started anyway.

### Service types

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

• Type=simple (default): systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
• Type=forking: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify PIDFile= as well so systemd can keep track of the main process.
• Type=oneshot: this is useful for scripts that do a single job and then exit. You may want to set RemainAfterExit=yes as well so that systemd still considers the service as active after the process has exited.
• Type=notify: identical to Type=simple, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by libsystemd-daemon.so.
• Type=dbus: the service is considered ready when the specified BusName appears on DBus's system bus.
• Type=idle: behavior of idle is very similar to Type=simple; however, actual execution of the service binary is delayed until all jobs are dispatched. This may be used to avoid interleaving of output of shell services with the status output on the console.

See man systemd.service for a more detailed explanation.

## Targets

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.


man systemd.target


# FAQ

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

#### Solution

// Edit /usr/lib/systemd/system/rc-local.service:
Edit $HOME/conf/rc-local.service:  [Unit] Description=/etc/rc.local compatibility [Service] Type=oneshot # 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 ExecStop= RemainAfterExit=yes [Install] WantedBy=multi-user.target  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.

# journalctl


# -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