This is the first of a series of tutorials about systemd. I find that most documentation on systemd is either -
In this post(and the upcoming posts) , we'll look at systemd in a (hopefully) non opinionated way and focus on the tech itself.
Systemd is the foundation of any modern linux system(other than the kernel, of course). When the Linux kernel finishes the initial boot process, the first process it starts is systemd. Systemd then takes over further starting up of other services/applications. These days, systemd handles a lot of other stuff like mounting drives/devices, managing the network, containers etc. So if you want to manage a modern linux system, chances are you will have to have a good idea of what systemd is and does.
Systemd is pretty new( and so, relatively unproven) in the grand scheme of things. Before systemd, there were other "init systems" as they are known, like systemv,upstart and openrc. Systemv was the most popular of these(it has now been replaced by systemd in most distributions).
A service(in the systemd context) is a pretty broad thing. It is generally a background process/processes started for a certain purpose. So for example, if you have a backup program that runs in the background, it probably has a systemd service that starts everyday to check for new files to backup.
Systemd also has other things like:
devices - the systemd representation of hardware devices like soundcards, USB controllers etc.mount - these generally are virtual filesystems like the tmp directory, and the kernel debug filesystem.slice - a slice is a group of processes. You can put resource limits on slices.sockets - systemd sockets are different than traditional UNIX sockets. Each service has a socket. The main advantage of sockets is that instead of starting the whole service, you can start the socket, which is much lighter. This makes the system listen for any incoming calls for the service. Then, when the system gets a call on the socket for the first time, the service is started.target - targets replace traditional runlevels. There are many more targets than there are runlevels, and multiple runlevels can be activated at the same time.timer - timers replace cron jobs. Each service can have a timer that describes when and at what interval the service is to be started.But in this part, we'll only look at basic service management and a few other things.
Most systemd functions are accessed through the systemctl command.
If you want to see all the running services(or units, as they are also called) in the system, just type systemctl without any arguments.
In this screenshot, you'll see all the running units in the system. You can see all the devices, and services.
If you want to look at just the failed units, you can run:
systemctl --failed
In my case, there are no failed units.
Let's take a unit - NetworkManager. and use it as an example to see some of the other commands that systemd has. The NetworkManager handles all networking related configuration.
To get some basic information about a service, you can use the status command, like so:
systemctl status NetworkManager
In this screenshot, we see a few things:
enabled ie. it will automatically start on boot.NetworkManager-ovs.conf and it's stored at /usr/lib/systemd/system/NetworkManager.service.d/. Most service files that come out of the box with the system are stored in the /usr/lib/systemd/system/ directory.man command.To stop a service, use the stop command, like so:
As you can see, after it's stopped, i haz no internet.
To start it again, use the start command:
NetworkManager is back up, and now i have internet again.
To enable a service(start it automatically at boot), use the enable command, like so:
systemctl enable NetworkManager
To disable something, use the disable command, like so:
systemctl disable NetworkManager
After disabling, if you look at the status,
On the second line, you'll see that the enabled in the previous status screenshot has been replaced by disabled. Note how, after disabling the service, it's still running.
If you want to completely remove a service, you can use the mask command:
To unmask it, simply use the unmask command:
To shutdown the system, you can use:
systemctl poweroff
To reboot the system, you can use:
systemctl reboot
To suspend the system, you can use:
systemctl suspend
So this is a feature of systemd that not a lot of people know about. It's pretty simple, so i'm going to show you how to use it in this part.
To look at the amount of time required for booting up, you can use systemd-analyze, like so:
So total boot time is around 4 seconds( if you are jealous of that, get an SSD ;-) ). Also, it took 2.322 seconds for graphical.target(ie. the desktop) to start.
These numbers exclude the time required for the BIOS to boot up. But if you have a UEFI system, you'll also see the amount of time taken by that.
If you want to see the time taken to start each service, you can use the blame command:
In this screenshot, we can see the the amount of time taken for each service to start up. So if you are experiencing slow boot times, you can use this command to find out which service is taking the most amount of time to start up.
If you want even more detail, you can use the plot command, which outputs an svg image, and pipe the output into a file like this:
systemd-analyze plot > Pictures/boot.svg
I'm not going to upload the actual image because it's really big, but this is a screenshot of a part of that image:
This shows the amount of time taken by each and every service that got activated on system boot.
This can actually be very useful for troubleshooting boot times. Originally, my boot times used to be much longer than 4 seconds. I used the systemd-analyze command, and found out that the thing that took the longest to start up was the manpage updater. I turned it off, and my boot times improved significantly.
This is the end of this part. In the next part, we'll look at writing our own service files(which is going to be a very useful thing to learn!)