Traditionally, halt is called at the end of the init script on
reboot/shutdown. To support such usecase, previously we read the current
runlevel from utmp and set force flag on reboot/shutdown.
This drops the support for such the usecase.
Note, neither supported nor tested, but hopefully still the command can
be used in the end of the sysv init script by specifying -ff.
Let's try to make clear that these calls really should not be extended
anymore, but remain as the compat glue they are but not more.
Anything new should really be added to systemctl poweroff/halt/reboot,
which is actually defined and owned by us.
This is added in light of a9c3cc8db0 which
really shouldn't have been added I am sure.
This adds two things: a note to the --help text that people use the
relevant systemctl commands instead (as they are a lot more powerful,
for example give you inhibitor and boot loader control, kexec, and so
on). And a note to developers that they stop adding new stuff to the
compat interfaces.
For shutdowns don't fall back to starting the target directly if talking
to logind failed with auth failure. That would just lead to another
polkit auth attempt.
The code at this point is not able to tell whether it was called as
halt/poweroff/reboot or shutdown with time "now".
The code also takes a shortcut to skip logind if called as root.
That however means asking shutdown for immediate action won't trigger a
wall message.
As per https://github.com/systemd/systemd/issues/8424#issuecomment-374677315
all commands should trigger a wall message.
That simplifies the code as we can try logind first always.
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
I think this formatting was originally used because it simplified
adding new options to the help messages. However, these days, most
tools their help message end with "\nSee the %s for details.\n" so
the final line almost never has to be edited which eliminates the
benefit of the custom formatting used for printf() help messages.
Let's make things more consistent and use the same formatting for
printf() help messages that we use everywhere else.
Prompted by https://github.com/systemd/systemd/pull/18355#discussion_r567241580
This is just some refactoring: shifting around of code, not change in
codeflow.
This splits up the way too huge systemctl.c in multiple more easily
digestable files. It roughly follows the rule that each family of verbs
gets its own .c/.h file pair, and so do all the compat executable names
we support. Plus three extra files for sysv compat (which existed before
already, but I renamed slightly, to get the systemctl- prefix lik
everything else), a -util file with generic stuff everything uses, and a
-logind file with everything that talks directly to logind instead of
PID1.
systemctl is still a bit too complex for my taste, but I think this way
itc omes in a more digestable bits at least.
No change of behaviour, just reshuffling of some code.
Yu Watanabe
Daan De Meyer
Mike Yuan
Lennart Poettering
Ludwig Nussel
Zbigniew Jędrzejewski-Szmek
Deepak Rawat