SystemD - What is SystemD used for?

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 A Kegerator Used For? Super...
What Is A Kegerator Used For? Superb 4 Facts About Kegerator That You Must Know!

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

SystemD Top Image

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:

PathInfo
/usr/lib/systemd/systempredefined SystemD files (do not modify)
/etc/systemd/systemLocation for custom unit files
/run/systemd/systemFor 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:

[email protected]:~$ 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:

[email protected]:~$ 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:

CommandFunction
enableActivates a service
disableDisables a service
is-enableCheck if a service is enabled
reenabledisables a service and then enables it again
maskIf you want to completely disable a service, mask him - Be careful
unmaskunmasks 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:

TargetEffect
halt.targetShut down the system
poweroff.targetPhysically shuts down the system (power off)
rescue.targetSingle User mode
multi-user.targetMultiuser mode
graphical.targetMultiuser mode with graphical interface
reboot.targetReboots 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)
[email protected]:~$ 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.

[email protected]:~$ 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:

[email protected]:~$ 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:

[email protected]:~$ 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

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share via
Copy link
Powered by Social Snap