One common complaint about systemd is that it does «too much», where the threshold for the appropriate amount of action is left unspecified. Some of the stuff it can do is hold your hand and offer some comfort functions.
is that you don’t need to know where your unit files are. You can, and systemd
will tell you, but you don’t need to know the path a priori. So here are some
systemctl that you don’t need to know about, but which can make
your life a little easier.
This will print your service file, with the path in a comment at the top:
$ systemctl cat systemd-journald.service # /usr/lib/systemd/system/systemd-journald.service # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it ## blah blah blah…
The first line with the path is not actually included in the service file, and
there’s a good chance it’ll be printed in another color on your machine. This
will print the unit file that systemd will actually use for that unit. In this
case it’s running the vendor-supplied unit file, which you can tell by the fact
that it’s in
/usr/lib/systemd; your files are supposed to go in
/etc/systemd/. Unless it’s a temporary file, they go in
/run/systemd, or it
might be a user file, in yet another set of paths that I don’t actually care to
remember or think about. Hence this blog post.
Now, if you for some reason need to change a unit file, use
systemctl edit. I
systemctl edit --full which will give you the full file to edit, rather
than expecting you to write a replacement snippet blind.
systemctl edit will
give you the appropriate file to edit, and save it in the appropriate place,
and it will run
systemctl daemon-reload. And of course it relies on ed, the
By default (without
--full) it will create an appropriate
--full it will create a
foo.$unit. My intuition
tells me that if I make no changes, no new file will be written, and that’s
correct for the default version, but with
--full you’re in effect creating
a copy of the vendor unit file as it exists at that time.
If you need to delete something from a unit file, use
--full and delete the
It has some extra features:
--forceis handy if you want to start a brand new unit file: it’ll create a unit file with that name if one doesn’t already exist. Requiring this to create new unit files means you won’t inadvertently create a new unit file if you do a typo or are confused about what the service name is (like me, I always expect «postgres», not «postgresql» (yes, I know about autocompletion)).
--runtimemakes a temporary edit that will be lost on the next reboot.
Once you’ve edited a unit file, it can start diverging even more from the
vendor-supplied one as upstream thinks up new and exciting ways to do
systemd-delta shows you how your system is different from a
vanilla system, with diffs for overrides, which file supercedes what, and so
on. Sadly, the output from
systemd-delta isn’t sorted or stable, and there’s
If you’ve used
edit to create a
foo.d/override.conf, it’ll show up as
[EXTENDED]. If you used
--full and made a copy, it’ll show up as
[OVERRIDDEN]. The naming makes sense if you think about it, although it would
be OK too if I didn’t have to think and the
override.conf version matched with
This is a very simple indicator of whether systemd thinks everything is running
systemctl is-system-running outputs the same thing as the «State»
- What you want is «running» and exit code 0.
- What you might get is «degraded» and exit code > 0. In that case, do
systemctl list-units --state=failedto see what it’s unhappy about. If you don’t want to fix something, you can comfort systemd by telling it
systemctl reset-failed $foo. This will not restart services or anything, it will just convince systemd that things are fine (morbid comic).
- There are other options, which are listed in table form in systemctl(1).
So by adding
systemctl is-system-running to your login script or monitoring
system, you can get a quick feel for whether something is
¹ Blatant lie. It uses