The many powers of Systemd, strung with intimate access to your system, as any init system would be. SystemD can power or schedule background processes, or you can even use it to boot your Linux installations. Today, our interest is how to use it to track our service logs. We have a blog about how to use SystemD to set up automatic updates that can be found here. We also have another blog about enabling and disabling services using SystemD here. The best part is, you actually have so much power over your system once you learn how to use SystemD. Arguably, the next most powerful system after the Linux kernel itself.
Today we will go over how to look as SystemD units from journalctl as limited as that can actually be. We don’t want to leave out anything important. Next, we will cover systemctl with even more detail, since that is what you are here for. Even though some folks rather make Artix than run Arch with SystemD, you will really have way more control over your system just due to the availability of documentation alone. Let’s get right into it.
Journalctl Logs
One way to see what a service unit is doing is to check it out running journalctl. You will want to run this on anything you are suspicious about, or perhaps just curious about. You can start by just running the tried and true flag -h.
journalctl -h
This will give you all the flags and options available. This way, you will be able to try out other stuff that journalctl can do.
Now you can see the filtering option we will use to check out some system units.
journalctl -u sddm
You will need to change sddm to what ever you are interested in checking out. Simple as that, you will have more information about your system.
Systemctl Logs
Here are the goods that you came for, systemctl will tell you a lot. This SystemD tool will tell you everything you ever wanted to know about SystemD services and timers. From checking if all the units are loading on your system, to going ham, and check each service bit-by-bit. So let’s start off with the tried and true flag of all time -h.
systemctl -h
Now much like before in the previous section we will see many options. The difference here is that all of them have to do with SystemD units and not so much with other stuff that journalctl keeps logs on.
From this point we will really work on how much we can check on. Let’s find out if our system is firing on all cylinders.
systemctl status
You can see that my laptop is running on all cylinders. Otherwise, you would see red lettering indicating the failed service, and then you will have a lead to go on. Let us say for the instance you are writing a service. We can also run this with a particular service in mind.
systemctl status NetworkManager
Here, if NetworkManager had failed on boot, you would see red letters again rather the green. Also, you would have a log below it that will show the details. Let’s see about sddm.
systemctl status sddm
On this image, you can see that sddm had an issue on the top line of the log. But was still successful with functionality. Thus, the color is nice and green. You may also be testing a service that you wrote. If it does not show up during systemctl status command, then it is not running at all. So you should be able to troubleshoot anything, what ever you are trying to do.
More SystemD
Now if you are looking to get a service working you might need to find out if the dependencies are installed. It is as easy as the list-dependencies option.
In this image, you can see some of the dependencies of sddm. There are more, but you get the idea. You can even invite cat to the party. We don’t have to look for the config file to see what the contents are. All you need to do is run the command together like this.
systemctl cat sddm
This can save you time when trying to write a service. That way, you can check your work to make sure that the service you are writing is correct. We have one final extra command to leave you with. Sometimes you may need to know the properties of a service to help you figure some stuff out. You can do this with the show option.
systemctl show sddm
Now you should have more than enough knowledge to see the logs you need, as well as the ability to write your own services with the tools to investigate potential issues. You can never have too many tools in your bag to pull out when you need them most. Thanks for reading.
