# Systemd

We can create all sockets for all daemons in one step in the init system, and then in a second step run all daemons at once. - Rethinking PID 1 / systemd

Basic commands

Regular users can start their own services (using --user flags, and definition in $HOME/.config/containers/systemd/)

systemctl status
systemctl enable/disable => service launch on host startup
systemctl start/stop => immediate operation

journalctl -e => most recent entries journalctl -b => boot messages

A good metric for measuring shell script infestation of the boot process is the PID number of the first process you can start after the system is fully booted up. Boot up, log in, open a terminal, and type echo $$.

Keep a USER process alive

In systemd, user services are managed by systemd --user. By default, user services are started when the user logs in and are terminated when the user logs out. However, if you want a user service to start even if the user is not logged in, you can achieve this by using lingering sessions. Lingering allows user services to continue running in the background even if the user is not actively logged in.

sudo loginctl enable-linger <username>

otherwise in /etc/systemd/logind.conf change flags (otherwise process will be killed when user exit)

KillUserProcesses=no

Update service definition

systemctl daemon-reload
systemctl restart your-service-name

State: degraded

original issue caused by apparmor not starting - How to disable AppArmor

systemctl --failed => to list which services failed to start

Service

There are basically two places in the filesystem where systemd service units are installed: /usr/lib/systemd/system and /etc/systemd/system. The former path is used for services provided by installed packages, while the latter can be used by the system administrator for its own services which can override the default ones.

sudo cp wol.service /etc/systemd/system && sudo systemctl start wol.service

systemd Shutdown Units

Designing a system to shutdown gracefully can be tricky. In an ideal world, every service would be managed by a systemd unit. ExecStart would start a process that handles SIGTERM by stopping itself and an ExecStop would inform the process and block to gracefully stop the process and its resources.

But not all software stops gracefully or does a full teardown of what it set up. In this post, we’ll look at systemd’s shutdown behavior and strategies for writing systemd units that perform custom cleanup tasks before shutdown.

#4577