SystemD is a system management tool that is used to streamline system administration tasks and improve efficiency. Its primary benefit lies in its ability to improve system performance and responsiveness, as well as improve security by automatically scanning for vulnerabilities and patching them.
Additionally, SystemD can help organize system resources more effectively, allowing programs to run faster and smoother. Overall, if you are looking for an effective system management tool that will help you get the most out of your system, then SystemD is the ideal solution. In this article, you will learn everything you need to know about SystemD.
Table of Contents
- What is SystemD used for?
- Why do people dislike SystemD?
- Why is SystemD controversial?
- What is SystemD vs init?
- Should I use Grub or SystemD?
- How to use SystemD
- SystemD – Init
- Unit-Files
- Targets
- Control-Groups
- Logging – JournalD
- Summary
What is SystemD used for?
SystemD is a system management tool that can be used for a variety of tasks, from managing system resources and processes to optimizing system performance on Linux systems. It is widely used in many different industries, from healthcare to manufacturing, due to its powerful capabilities and advanced features.
Whether you are running large servers or smaller workstations, SystemD offers a range of benefits that can help you improve system efficiency and productivity. Some of the key features include process prioritization, system event logging, and system resource allocation controls. So if your organization is looking for a reliable system management tool that can help boost efficiency and performance across all systems, then SystemD is definitely worth considering.
Why do people dislike SystemD?
While many users find SystemD to be an invaluable system management tool, there are some who dislike it for a variety of reasons. Some critics argue that it is overly complex and difficult to use, especially for those who are not familiar with system administration tasks. Others claim that it can negatively impact system performance, leading to slower startup times and increased resource usage.
Despite these concerns, however, SystemD remains one of the most widely used system management tools on the market today and will likely continue to be so in the future. If you are looking for an efficient system management tool that can help improve productivity across your organization’s systems, then SystemD is definitely worth considering.
Why is SystemD controversial?
SystemD is a highly controversial system management tool, largely due to the ongoing debate around its effectiveness and usability. Some users claim that it can negatively impact system performance, while others argue that it offers a number of important benefits, such as improved system security and more efficient system resource allocation.
There are also concerns about SystemD’s complexity and user-friendliness, with many users citing its steep learning curve and confusing interface as major points of criticism. Despite these concerns, however, SystemD remains one of the most widely used system management tools on the market today and is likely to continue to be so in the future. If you are looking for a powerful system management tool that can help improve system performance and efficiency across all systems, then SystemD may be the ideal solution for you.
What is SystemD vs init?
SystemD and init are system management tools that are often compared due to their similar functions and overlapping features. While both system management tools can be used for a variety of system administration tasks, such as process prioritization, system event logging, and system resource allocation controls, there are some key differences between them.
While init is focused on system startup and shutdown processes, for example, SystemD offers a wider range of system management capabilities. Additionally, many users find SystemD to be more user-friendly and intuitive than init, making it a popular choice among system administrators and IT professionals. Overall, if you are looking for an effective system management solution that can help improve system performance and efficiency across all systems, then SystemD may be the ideal choice for you.
Should I use Grub or SystemD?
There is no definitive answer to this question, as both Grub and SystemD have their own benefits and drawbacks. On the one hand, Grub is a lightweight system management tool that offers simple, streamlined functions for system startup and shutdown.
On the other hand, SystemD offers a wider range of system management capabilities and features, making it a more powerful and versatile system management tool. Ultimately, whether you choose to use Grub or SystemD will depend on your specific needs and preferences as a system administrator or IT professional. However, if you are looking for an efficient system management solution that can help improve system performance and efficiency across all systems, then SystemD is likely the better choice.
How to use SystemD
Next, we will cover a couple of ways in which you can use SystemD on Linux systems. These are just a few examples that you can try out yourself. It takes some time to get used to the syntax, but once you have it down, SystemD becomes a powerful tool.
SystemD – Init
This is the first process started by the kernel and gets the process id 1. It manages the boot-process the tasks like creating sockets, setting up hardware, mounting disks, etc.
SystemD works with units of different types. Next to the service itself, there also exists:
- timer
- mount
- network
- sockets
- partitions
- devices
Furthermore, you can manage other processes with SystemD:
- start
- stop
- restart
- kill
Unit-Files
There are different paths for existing unit files:
| Path | Info |
|---|---|
| /usr/lib/systemd/system | predefined SystemD files (do not modify) |
| /etc/systemd/system | Location for custom unit files |
| /run/systemd/system | For the runtime relevant files |
Important information about the paths: SystemD will always prefer /etc/ to /usr/lib/. This is why we place custom unit files there.
You can visit the unit file of a specific service by visiting the path or with the command:
systemctl cat <service>
Code language: Bash (bash)For example, OpenVPN:
root@max-desktop:~$ systemctl cat openvpn
# /lib/systemd/system/openvpn.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)As we can see in the unit file, define which path is used, the PID file, and more options. Which we will discuss in more detail below. We can view all available properties with the options which can be defined in the unit file for the service by using the command:
systemctl show <service>
Code language: Bash (bash)For example, here again, are the first lines of the output of OpenVPN:
root@max-desktop:~$ systemctl show openvpn
Type=oneshot
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=infinity
TimeoutStopUSec=1min 30s
TimeoutAbortUSec=1min 30s
TimeoutStartFailureMode=terminate
TimeoutStopFailureMode=terminate
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestamp=n/a
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=yes
GuessMainPID=yes
MainPID=0
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
ReloadResult=success
CleanResult=success
UID=[not set]
GID=[not set]
NRestarts=0
OOMPolicy=stop
ExecMainStartTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainStartTimestampMonotonic=9823235
ExecMainExitTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainExitTimestampMonotonic=9824084
ExecMainPID=1164
ExecMainCode=1
ExecMainStatus=0v
Code language: Bash (bash)If we now want to edit the unit file of the service, we run the command:
systemctl edit --full <service>
Code language: Bash (bash)When we run the command without the full option, we will get a blank file. We have the option to create a copy of the source file, which we can edit.
As an example of a possible option, let’s imagine we want that OpenVPN is always running. Even when the process is getting stopped or killed, we want that it restarts by itself.
We open the editor and add the specific option:
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Restart=yes
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)After this, we need to reload the configuration file:
systemctl reload <service>
Code language: Bash (bash)And finally, restart the service:
systemctl restart <service>
Code language: Bash (bash)With this command, SystemD will try to reload the service. If this doesn’t work, it will restart the service:
systemctl reload-or-restart <service>
Code language: HTML, XML (xml)In the above commands, we learned how to control services manually. SystemD also allows you to permanently enable or disable services so that they either start automatically when needed or are not available at all. The following table will show the available commands:
| Command | Function |
|---|---|
| enable | Activates a service |
| disable | Disables a service |
| is-enable | Check if a service is enabled |
| reenable | disables a service and then enables it again |
| mask | If you want to completely disable a service, mask him – Be careful |
| unmask | unmasks a service |
Usage example:
systemctl enable <service>
Code language: Bash (bash)Targets
These are different states in which the system can boot.
SystemD adds a new concept for the well-known run levels. However, the older principle is retained. Only the run levels are given names instead of numbers:
| Target | Effect |
|---|---|
| halt.target | Shut down the system |
| poweroff.target | Physically shuts down the system (power off) |
| rescue.target | Single User mode |
| multi-user.target | Multiuser mode |
| graphical.target | Multiuser mode with graphical interface |
| reboot.target | Reboots the system |
You can switch to another target by using the following command:
systemctl isolate example.target
Code language: Bash (bash)Reboot the system:
systemctl reboot
Code language: Bash (bash)Puts the system into a deep sleep and pauses all running processes:
systemctl hybrid-sleep
Code language: Bash (bash)Powers off the system with a broadcast message to all logged-in users:
systemctl shutdown
You can modify this by using the parameters:
systemctl shutdown -r now
Code language: Bash (bash)This would reboot the system (-r) and bypass the broadcast message, and reboots directly. There are many different parameters to use this command. You can look them up on the man-page.
You can display the current target the system is booting into with the following command:
systemctl get-default
Code language: Bash (bash)Additional, you can modify the target:
systemctl set-default example.target
Code language: Bash (bash)The different runlevels can also be viewed here:
ls -la /usr/lib/systemd/system |grep runle*
Code language: Bash (bash)root@max-desktop:~$ ls -la /usr/lib/systemd/system |grep runle*
lrwxrwxrwx 1 root root 15 Apr 18 22:12 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel1.target -> rescue.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel1.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel2.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel2.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel3.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel3.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel4.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel4.target.wants
lrwxrwxrwx 1 root root 16 Apr 18 22:12 runlevel5.target -> graphical.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel5.target.wants
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel6.target -> reboot.target
-rw-r--r-- 1 root root 803 Apr 18 22:12 systemd-update-utmp-runlevel.service
Code language: plaintext (plaintext)Control-Groups
SystemD organizes Tasks in control groups. This is used for resource control in Linux, and this allows available resources to be limited, prioritized, counted, and isolated.
The following commands are, therefore, very useful for analyzing and optimizing system performance:
systemd-analyze
Code language: Bash (bash)This command can be used to determine boot performance.
root@max-desktop:~$ systemd-analyze
Startup finished in 12.712s (firmware) + 328ms (loader) + 8.240s (kernel) + 6.634s (userspace) = 27.916s
graphical.target reached after 6.631s in userspace
Code language: plaintext (plaintext)As we can see, we get a breakdown of the timings of how long each task takes to start.
With the additional command blame we get a very detailed list of how long which single process needs to start up:
systemd-analyze blame
Output:
root@max-desktop:~$ systemd-analyze blame
5.573s NetworkManager-wait-online.service
3.244s plymouth-quit-wait.service
2.285s fwupd.service
467ms logrotate.service
392ms lm-sensors.service
385ms accounts-daemon.service
362ms snapd.service
290ms systemd-resolved.service
279ms networkd-dispatcher.service
247ms networking.service
213ms dev-nvme0n1p3.device
182ms apparmor.service
178ms ModemManager.service
174ms systemd-journal-flush.service
168ms udisks2.service
161ms NetworkManager.service
152ms com.system76.Scheduler.service
128ms apport.service
127ms e2scrub_reap.service
116ms rsyslog.service
115ms smartmontools.service
114ms wpa_supplicant.service
105ms [email protected]
100ms gpu-manager.service
....
Code language: plaintext (plaintext)If we want to see all control groups, we can use:
systemd-cgls
Code language: Bash (bash)or
systemctl status
Code language: Bash (bash)We will get a tree-based output with all the necessary information:
root@max-desktop:~$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│ ├─[email protected]
│ │ ├─session.slice
│ │ │ ├─dbus-broker.service
│ │ │ │ ├─3119 /usr/bin/dbus-broker-launch --scope user
│ │ │ │ └─3120 dbus-broker --log 4 --controller 10 --machine-id 04d8535513777afc7bb291c362dd90a7 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 50000000>
│ │ │ ├─xdg-document-portal.service
│ │ │ │ ├─3761 /usr/libexec/xdg-document-portal
│ │ │ │ └─3773 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc
│ │ │ ├─xdg-desktop-portal.service
│ │ │ │ └─3753 /usr/libexec/xdg-desktop-portal
│ │ │ ├─pipewire-pulse.service
│ │ │ │ └─3112 /usr/bin/pipewire-pulse
│ │ │ ├─wireplumber.service
│ │ │ │ └─3111 /usr/bin/wireplumber
│ │ │ ├─plasma-xdg-desktop-portal-kde.service
│ │ │ │ └─3861 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
│ │ │ └─pipewire.service
│ │ │ └─3106 /usr/bin/pipewire
│ │ ├─background.slice
│ │ │ ├─plasma-kactivitymanagerd.service
│ │ │ │ └─3546 /usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd
│ │ │ ├─plasma-kscreen.service
│ │ │ │ └─3610 /usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher
│ │ │ ├─plasma-baloorunner.service
│ │ │ │ └─5633 /usr/lib/x86_64-linux-gnu/libexec/baloorunner
│ │ │ ├─plasma-kglobalaccel.service
│ │ │ │ └─3452 /usr/bin/kglobalaccel5
│ │ │ └─tracker-miner-fs-3.service
│ │ │ └─3148 /usr/libexec/tracker-miner-fs-3
│ │ ├─app.slice
│ │ │ ├─app-\\x2fusr\\x2fbin\\x2fkorgac-d27ecb9065d646918a10df1c4fa798fe.scope
│ │ │ │ └─3599 /usr/bin/korgac -session 10dfe2702d000165869202400000083140007_1663442587_18526
│ │ │ ├─gvfs-goa-volume-monitor.service
│ │ │ │ └─3171 /usr/libexec/gvfs-goa-volume-monitor
│ │ │ ├─app-dbus\\x2d:1.2\\x2dorg.gnome.OnlineAccounts.slice
│ │ │ │ └─dbus-:[email protected]
│ │ │ │ └─3174 /usr/libexec/goa-daemon
│ │ │ ├─xdg-permission-store.service
│ │ │ │ └─3765 /usr/libexec/xdg-permission-store
│ │ │ ├─com.system76.SystemUpdater.Local.service
Code language: plaintext (plaintext)With the systemd-cgtop command, we get a list of all control groups sorted by the current resource utilization:
systemd-cgtop
Code language: Bash (bash)Now, why is this important to us? Now we can analyze the resource utilization of individual processes and, if necessary, adjust the process’s priority or change the resource limit.
The man page gives us many possibilities to manage this:
man systemd.resource-control
Code language: Bash (bash)For example – if we want to set the memory limit of a specific service, we can use:
systemctl set property example.service MemoryLimit=1G
Code language: Bash (bash)Logging – JournalD
JournalD logs all events in the RAM of the system. This will be cleared with a system restart.
You can use JournalD with the following command:
journalctl
Code language: Bash (bash)We can further refine the output by adding filters, for example, with a specific time:
journalctl --since yesterday
Code language: Bash (bash)We can refine it even more by specifying an exact time period from to:
journalctl --since "date" --until "date"
Code language: Bash (bash)Another way to filter is to follow specific services:
journalctl -u example
Code language: Bash (bash)We can also follow a specific service and filter just for this one:
journalctl -fu example
Code language: Bash (bash)We could also filter just for kernel events:
journalctl -k
Code language: Bash (bash)Summary
SystemD is a strong successor to the classic System V init daemon and provides the admin with a lot of useful information and tools that speed up everyday work and workflow. If you want to learn more about other in-depth Linux topics, make sure to visit Max Wilke’s blog.
- SystemD is a system management tool that can be used for tasks such as managing system resources and processes, optimizing system performance, and improving security.
- SystemD offers a number of benefits that can help organizations improve efficiency and productivity, including process prioritization, system event logging, and resource allocation controls.
- While SystemD is widely used by many different industries due to its powerful capabilities, some users dislike it because it is complex or difficult to use. Additionally, some critics argue that it can negatively impact system performance.
- Despite these concerns, SystemD remains one of the most popular systems management tools on the market today.
🐧 There are some related articles!
👉 Top Things to do after installing Kali Linux
👉 Linux on Windows – The Complete WSL 2 Tutorial Series
👉 Create Generalized Windows Images with FOG Server
👉 Install FOG Server on Ubuntu
👉 Install Kali Linux on Windows – Complete Guide
👉 The Complete Kali Linux and Windows Dual Booting Guide
👉 Cronjob – The Complete Guide to Cronjobs
👉 Open Bitlocker Drive on Linux – Quick & Easy
