(no title)
stoplight | 10 years ago
> Try to find the answer to "which units are going to be started on next boot?".
Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up)
Also the other states:
> Speaking of which, why is systemctl daemon-reload even a thing?
Because configuration changes while things are running. Otherwise we wouldn't need apache2 reload, nginx reload, haproxy reload, etc. Also, according to the man page:
> After the units have been edited, systemd configuration is reloaded (in a way that is equivalent to daemon-reload).
As for systemctl edit, it allows you to add diffs to the unit file. For example, let's say I am using redis and I want to ensure it always restarts (for whatever reason). Rather than manually editing the unit file (which will have issues if an upstream change happens), I can simply use systemctl edit to add a diff for my change. This way I can still maintain compatibility with the upstream unit file instead of having to deal with potential conflicts. It's not so much babysitting the user as it is a potentially better experience.
ploxiln|10 years ago
Nope.
There are many virtual units for which there are no files. One example is the on-demand getty units. There are two for "plymouth" boot-splash stuff (I see these attempted-and-failed units on archlinux where plymouth never exists). There's some autofs thing. There's auditd.
I'm actually not booted into linux right now so I'm struggling to remember the specifics... but if you also count all the simple mounts and devices which clutter up the output of "systemd --all" as "units which are not files in /etc/systemd" then the count is around 100.
groks|10 years ago
INTPenis|10 years ago
I'm not familiar enough with systemd to understand how to trace dependencies and create a complete list of all units that will run at next boot but I expect this to be doable by someone with that expertise.