These are the notes of a training course on systemd I gave as part of my work
with
Truelite.
Exploring the state of a system
systemctl status [unitname [unitname..]] show status of one or more units,
or of the whole system. Glob patterns also work: systemctl status "systemd-fsck@*"systemctl list-units or just systemctl show a table with all units, their
status and their descriptionsystemctl list-sockets lists listening sockets managed by systemd and what
they activatesystemctl list-timers lists timer-activated units, with information about
when they last ran and when they will run againsystemctl is-active [pattern] checks if one or more units are in active statesystemctl is-enabled [pattern] checks if one or more units are enabledsystemctl is-failed [pattern] checks if one or more units are in failed statesystemctl list-dependencies [unitname] lists the dependencies of a unit, or
a system-wide dependency treesystemctl is-system-running check if the system is running correctly, or if
some unit is in a failed statesystemd-cgtop like top
but processes are aggregated by unitsystemd-analyze produces reports on boot time, per-unit boot time charts,
dependency graphs, and more
Start and stop services
Similar to the System V
service command,
systemctl provides commands to start/stop/restart/reload units or services:
start: starts a unit if it is not already startedstop: stops a unitrestart: starts or restarts a unitreload: tell a unit to reload its configuration (if it supports it)try-restart: restarts a unit only if it is already active, otherwise do nothing, to prevent accidentally starting a servicereload-or-restart: tell a unit to reload its configuration if supported, otherwise restart ittry-reload-or-restart: tell a unit to reload its configuration if supported, otherwise restart it. If the unit is not already active, do nothing to prevent accidentally starting a service.
Changing global system state
systemctl has
halt,
poweroff,
reboot,
suspend,
hibernate, and
hybrid-sleep commands to tell systemd to reboot, power off, suspend and so
on.
kexec and
switch-root also work.
The
rescue and
emergency commands switch the system to rescue and emergency
mode (see
man systemd.special.
systemctl default switches to the default mode, which also happens when
exiting the rescue or emergency shell.
Run services at boot
systemd does not implement runlevels, and services start at boot based on their
dependencies.
To start a service at boot, you add to its
.service file a
WantedBy=
dependency on a well-known
.target unit.
At boot, systemd brings up the whole chain of dependency started from a default
unit, and that will eventually activate also your service.
See
systemctl get-default for what unit is currently the default in your
system. You can change it via the
systemd.unit= kernel command line,
so you can configure multiple entries in the boot loader that boot the system
running different services. For example
systemd.unit=rescue.target for a
rescue mode,
systemd.unit=multi-user.target for a non-graphical mode, or add
your own
.target file to implement new system modes.
See
systemctl list-units -t target --all for a list of all currently
available targets in your system.
systemctl enable unitname enables the unit to start at boot, by creating
symlinks to it in the .wants directory of the units listed in its
WantedBy= configurationsystemctl disable unitname removes the symlinks created by enablesystemctl reenable unitname removes and readds the symlinks for when you
changed WantedBy=
Notes:
systemctl start activates a unit right now, but does not automatically
enable it at boot
systemctl enable enables a unit at boot, but does not automatically start
it right now
* a disabled unit can still be activated if another unit depends on it
To disable a unit so that it will never get started even if another unit
depends on it, use
systemctl mask unitname. Use
systemctl unmask unitname
to undo the masking.
Reloading / restarting systemd
systemctl daemon-reload tells systemd to reload its configuration.
systemctl daemon-reexec tells systemd to restart iself.
So recently I was in York at the Bytemark office, and I read a piece about building a radio in a Raspberry Pi magazine. It got me curious, so when I got home to sunny Helsinki I figured I'd have a stab at it.
I don't have fixed goal in mind, but what I do have is:
A maintenance update 
Here s my weekly report for week 38 of 2017. This week has not been a great
week as I saw my primary development machine 
