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.
This normalizes naming of functions operating on BootConfig objects.
Let's always call them boot_config_xyz(), like our usual way to name
stuff.
moreover, move the BootConfig parameter to the beginning, as it's not a
return value (which we typically move to the end of the parameter list),
but simply an object, that even happens to be initialized already.
With these changes the functions are more like our usual way to call
things, and less surprises are good.
Same idea as 03677889f0.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
We should treat ./some.service and $PWD/some.service as equivalent. But we'd
try to send the relative paths over dbus, which can't work well:
$ sudo systemctl enable ./test2.service
Failed to look up unit file state: Invalid argument
$ sudo systemctl enable $PWD/test2.service
Created symlink /etc/systemd/system/multi-user.target.wants/test2.service → /home/zbyszek/src/systemd/test2.service.
Created symlink /etc/systemd/system/test2.service → /home/zbyszek/src/systemd/test2.service.
Now both are equivalent.
The fall-through to reboot doesn't seem to make sense. It won't happen
in the current code. Filtering the actions on client side is not needed
either as the server will refuse unsupported operations anyway.
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.
Currently the `--timestamp=` option has no effect on timestamps shown by
`systemctl show`, let's fix that.
Spotted in #22567.
Before:
```
$ systemctl show --timestamp=us+utc systemd-journald | grep Timestamp=
ExecMainStartTimestamp=Sat 2021-12-11 15:25:57 CET
StateChangeTimestamp=Sat 2021-12-11 15:25:57 CET
InactiveExitTimestamp=Sat 2021-12-11 15:25:57 CET
ActiveEnterTimestamp=Sat 2021-12-11 15:25:57 CET
ActiveExitTimestamp=Sat 2021-12-11 15:25:57 CET
InactiveEnterTimestamp=Sat 2021-12-11 15:25:57 CET
ConditionTimestamp=Sat 2021-12-11 15:25:57 CET
AssertTimestamp=Sat 2021-12-11 15:25:57 CET
```
After:
```
$ systemctl show --timestamp=us+utc systemd-journald | grep Timestamp=
ExecMainStartTimestamp=Sat 2021-12-11 14:25:57.177848 UTC
StateChangeTimestamp=Sat 2021-12-11 14:25:57.196714 UTC
InactiveExitTimestamp=Sat 2021-12-11 14:25:57.177871 UTC
ActiveEnterTimestamp=Sat 2021-12-11 14:25:57.196714 UTC
ActiveExitTimestamp=Sat 2021-12-11 14:25:57.144677 UTC
InactiveEnterTimestamp=Sat 2021-12-11 14:25:57.176331 UTC
ConditionTimestamp=Sat 2021-12-11 14:25:57.176980 UTC
AssertTimestamp=Sat 2021-12-11 14:25:57.176980 UTC
```
It's totally not OK to write to the strings returned by it, the data is
shared by all code that references the message.
While we are at it, simplify the code via
json_variant_set_field_string().
Follow-up for: 5ef599b324
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.
This commit adds a function which converts a bus message containing the
environment variables to a JSON object and uses this function to support
JSON formatted output for the "systemctl show-environment" command.
Fixes#21348
Previously the mkdir_label() family of calls was implemented in
src/shared/mkdir-label.c but its functions partly declared ins
src/shared/label.h and partly in src/basic/mkdir.h (!!). That's weird
(and wrong).
Let's clean this up, and add a proper mkdir-label.h matching the .c
file.
(Or when -H is used, since -H and -M are incompatible.)
Note that the slightly unusual form with separate boolean variables (hint_vars,
hint_addr) instead of e.g. a const char* variable to hold the message, because this
way we don't trigger the warning about non-literal format.
This shows the cgroup tree of the root slice of the container now, by
querying the cgroup pid tree via the bus instead of going directly to
the cgroupfs.
A fallback is kept for really old systemd versions where querying the
PID tree was not available.
Fixes: #20958
Otherwise we likely show rubbish because even in local containers we
nowadays have cgroup namespacing, hence we likely can't access the
cgroup tree from the host at the same place as inside the container.
When combined with a tmpfs on /run or /var/lib, allows to create
arbitrary and ephemeral symlinks for StateDirectory or RuntimeDirectory.
This is especially useful when sharing these directories between
different services, to make the same state/runtime directory 'backend'
appear as different names to each service, so that they can be added/removed
to a sharing agreement transparently, without code changes.
An example (simplified, but real) use case:
foo.service:
StateDirectory=foo
bar.service:
StateDirectory=bar
foo.service.d/shared.conf:
StateDirectory=
StateDirectory=shared:foo
bar.service.d/shared.conf:
StateDirectory=
StateDirectory=shared:bar
foo and bar use respectively /var/lib/foo and /var/lib/bar. Then
the orchestration layer decides to stop this sharing, the drop-in
can be removed. The services won't need any update and will keep
working and being able to store state, transparently.
To keep backward compatibility, new DBUS messages are added.
When we are in --user mode there's no point in doing PolicyKit/ask-pw
because both of these systems are only used by system-level services.
Let's disable the two agents for that automaticlly hence.
Prompted by: #20576
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Yu Watanabe
Ludwig Nussel
Daan De Meyer
Frantisek Sumsal
Jan Janssen
Joris Hartog
Amir Omidi
Luca Boccassi
Iago López Galeiras