Systemd is a software suite of daemons, libraries and administration utilities designed with the aim of centralizing the management and configuration of Unix-like operating systems.
Systemd is generally used as init system to use to bootstrap user space during startup and manage user processes. It replaces the classic origin, which is the descending one from the Unix System V (SysVinit). It was born for Red Hat Linux and later adopted in Debian. It’s obviously free software and it is distributed under the GNU LGPL 2.1 license or later. One of the main goals of systemd is to unify the basic configuration of the services of the main distributions.
Inits, daemons and runlevels
In a Unix operating system, an init is the first process that the kernel executes after the computer has finished the bootstrap phase. It has the task of bringing the system into an operational state, starting the necessary programs and services. Also, like an init daemon, systemd is a daemon that manages other daemons, which, including systemd itself, are background processes. systemd is the first daemon to start during booting and the last daemon to terminate during the shutdown.
Since init is always the first process executed, it typically has PID 1. Its configuration file, on most systems, it is
/etc/inittab. This file is the configuration file used by the System V (SysV) initialization system in Linux. It defines three items for the init process: the default runlevel, what processes to start, monitor, and restart if they terminate. Usually, init is configured to bring the system into different operational levels with different characteristics, called runlevels. For example, can exist a runlevel in which the system provides network services, such as HTTP and FTP, and can be convenient to have another runlevel in which these services are not provided, to be used in cases where network connectivity is missing or when maintenance is required.
Systemd is controversial for several reasons: It’s a replacement for something that a lot of Linux users don’t think needs to be replaced, and the antics of the systemd developers have not won hearts and minds. But rather the opposite, as evidenced in this famous LKML thread where Linus Torvalds banned systemd dev Kay Sievers from the Linux kernel.Understanding and Using Systemd | Linux.com
Basic usage, manuals and references
Systemctl is the main tool used to check and control the state of the systemd system and service manager. You can use systemctl for instance to enable/disable services permanently or only for the current session.
$ systemctl status # to check system status
$ systemctl # to list all running services
$ systemctl start myservice # to activate the 'myservice' service
$ systemctl stop myservice # to deactivate the 'myservice' service
$ systemctl restart myservice # to restart the 'myservice' service
$ systemctl enable myservice # to enable the 'myservice' service to be started on boot
$ systemctl disable myservice # to disable the 'myservice' service to be started on boot
$ systemctl status myservice # to show the 'myservice' service status
Units are defined by individual configuration files, called unit files. The type of the unit is recognized by the file name suffix and the unit files usually are located in the
/lib/systemd/service/ system directory. Depend on distribution, but unit files can be stored in a few different places on your system and systemd usually (on Debian, Fedora and Ubuntu systems) looks for system unit files in this order:
/etc/systemd/system /run/systemd/system /usr/lib/systemd/system
Here the bluetooth.service on a Ubuntu 18.04 system:
[Unit] Description=Bluetooth service Documentation=man:bluetoothd(8) ConditionPathIsDirectory=/sys/class/bluetooth [Service] Type=dbus BusName=org.bluez ExecStart=/usr/lib/bluetooth/bluetoothd NotifyAccess=main #WatchdogSec=10 #Restart=on-failure CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE LimitNPROC=1 ProtectHome=true ProtectSystem=full [Install] WantedBy=bluetooth.target Alias=dbus-org.bluez.service
A lot of people don’t like systemd for various reasons, but at this state of things, if you’re using a distribution with systemd on board, it is better to learn and experiment with it because it can be pretty powerful and useful. If not, you can try the incredible Devuan GNU+Linux, a fork of Debian without systemd that offers users control over their system by avoiding unnecessary entanglements and ensuring Init Freedom.
Ok, if you stuck with systemd, here some references and useful manuals:
- systemd System and Service Manager – https://www.freedesktop.org/wiki/Software/systemd/
- manpages from the systemd project – https://www.freedesktop.org/software/systemd/man/
- the biggest myths about systemd – http://0pointer.de/blog/projects/the-biggest-myths.html
- systemd service manager wiki – https://wiki.debian.org/systemd
- understanding and administering systemd – https://docs.fedoraproject.org/en-US/quick-docs/understanding-and-administering-systemd/
- systemd unit file basics – https://fedoramagazine.org/systemd-getting-a-grip-on-units/