Neither of the callers of bus_deserialize_and_dump_unit_file_changes()
touches the changes array, so let's simplify things and keep it internal
to the function.
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
Otherwise under certain conditions `va_arg()` might get garbage instead
of the expected value, i.e.:
$ sudo build-o0/systemctl disable asdfasfaf
sd_bus_message_appendv: Got uint64_t: 0
Failed to disable unit: Unit file asdfasfaf.service does not exist.
$ sudo build-o1/systemctl disable asdfasfaf
sd_bus_message_appendv: Got uint64_t: 7954875719681572864
Failed to disable unit: Invalid argument
(reproduced on an armv7hl machine)
Resolves: #26568
Follow-up to: bf1bea43f1
Related issue: https://github.com/systemd/systemd/pull/14470#discussion_r362893735
In cases like packaging scripts, it might be desired to use
enable/disable on units without install info. So, adding an
option '--no-warn' to suppress the warning.
Trying to disable a unit with no install info is mostly useless, so
adding a warning like we do for enable (with the new dbus method
'DisableUnitFilesWithFlagsAndInstallInfo()'). Note that it would
still find and remove symlinks to the unit in /etc, regardless of
whether it has install info or not, just like before. And if there are
actually files to remove, we suppress the warning.
Fixes#17689
Some calls to lookup_path_init() were not followed by any log emission.
E.g.:
$ SYSTEMD_LOG_LEVEL=debug systemctl --root=/missing enable unit; echo $?
1
Let's add a helper function and use it in various places.
$ SYSTEMD_LOG_LEVEL=debug build/systemctl --root=/missing enable unit; echo $?
Failed to initialize unit search paths for root directory /missing: No such file or directory
1
$ SYSTEMCTL_SKIP_SYSV=1 build/systemctl --root=/missing enable unit; echo $?
Failed to initialize unit search paths for root directory /missing: No such file or directory
Failed to enable: No such file or directory.
1
The repeated error in the second case is not very nice, but this is a niche
case and I don't think it's worth the trouble to trying to avoid it.
Let's split out the inner parts of verb_daemon_reload() as a function
daemon_reload() and then stop using the former outside of the verbs
logic, and instead call the latter whenever we need to reload the daemon
as auxiliary opeation.
This should make our logic more systematic as we don't have to provide
fake or misleading argc/argv to verb_daemon_reload() anymore.
Let's clean up our function naming a bit, and always name the
verb_xyz(), where the xyz maps to the command line verb as closely as
possible.
No actual code changes, just an attempt to make the systemctl sources a
bit more systematic, and less surprising.
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.
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.
G2-Games
Mike Yuan
David Tardon
Lennart Poettering
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Yu Watanabe