Currently only a single job for a single unit can be enqueued atomically,
so there is no guarantee that, e.g., starting a unit and its socket
at the same time will happen in the same transaction. That forces
callers to 'know' the right order in which to start new units being
installed, or failures will occur. It also means some ordering
constraints are ignored, in case the separate calls are done
in the wrong manual order.
Add a new EnqueueUnitJobMany() D-Bus method that takes a list of units
to start.
Fixes https://github.com/systemd/systemd/issues/8102
Co-authored-by: Michal Koutný <mkoutny@suse.com>
Let's cap the number of states/patterns per query to something
reasonable, i.e. max 256 states and 4K patterns per query.
---
Also, use the env assignments limit in a couple more places.
Introduce a counter that tracks how many configuration reloads have
been successfully completed by the manager. The increment lives in
manager_reload() right after the "point of no return", so failed
reload attempts that bail out earlier (e.g. during serialization)
do not bump the counter.
It is accessible as a new ReloadCount property to
org.freedesktop.systemd1.Manager (D-Bus) and ReloadCount to
io.systemd.Manager.Describe (Varlink).
Also add an integration test for ReloadCount
that verifies that the new ReloadCount property increments by one per
daemon-reload, accumulates correctly across multiple reloads, and that
D-Bus and Varlink return identical values. Also tests that the counter
reset after a reexec.
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Simon Lucido <simonlucido@meta.com>
Turns out we can utilize this limit at a couple more places, so let's
move the previously defined limit constant to env-util.h and use it to
guard a couple more D-Bus methods. Also, bump it a bit, given it's meant
to be a safety cap that can't be hit in valid scenarios.
Follow-up for 7671b43cb8.
Extract the transient unit setup logic from transient_unit_from_message()
in dbus-manager.c into a shared helper.
This prepares for reuse by the varlink StartTransient implementation.
This adds the low-level io.systemd.Manager shutdown support. This
is (much) simpler than the logind one. It mimics dbus but uses
a shared helper for the simple cases.
Note that this is more restrictive than the dbus version. The
dbus version uses SD_BUS_VTABLE_CAPABILITY(CAP_SYS_BOOT) but
the varlink version uses varlink_check_privileged_peer(link).
This is mostly because I'm not sure how to do the equivalent
in a race-free way.
Thanks to Daan for suggesting this.
Useful for packaging scripts, when units are removed.
When multiple markers are assigned without +/-, the last one wins.
When using +/-, the job merging logic is followed to the extent possible.
Previously, when `systemctl reload-or-restart --marked` failed the following
error was shown:
Failed to start jobs: Failed to enqueue some jobs, see logs for details: Invalid argument
but no details were actually logged.
This change records failure reasons in the journal to help users identify root causes:
# journalctl -b -e
[...]
systemd[1]: Queuing reload/restart jobs for marked units…
systemd[1]: Operation refused, unit klogd.service may be requested by dependency only (it is configured to refuse manual start/stop).
Closes#3829
Alternative to #35417
I don't think the individual "WasOnDependencyCycle" attrs on units
are particularly helpful and comprehensible, as it's really about
the dep relationship between them. And as discussed, the dependency
cycle is not something persistent, rather local to the currently
loaded set of units and shall be reset with daemon-reload (see also
https://github.com/systemd/systemd/issues/35642#issuecomment-2591296586).
Hence, let's report system state as degraded and point users to
the involved transactions when ordering cycles are encountered instead.
Combined with log messages added in 6912eb315f
it should achieve the goal of making ordering cycles more observable,
while avoiding all sorts of subtle bookkeeping in the service manager.
The degraded state can be reset via the existing ResetFailed() manager-wide
method.
Our baseline is v5.4 and cgroup v2 is enforced now,
which means CPU accounting is cheap everywhere without
requiring any controller, hence just remove the directive.
Currently there are various circular dependencies between headers
in core/. Let's get rid of these by making judicious use of forward
declarations and moving includes into implementation files instead of
having them in header files.
Getting rid of circular header includes simplifies the code and makes
various clang based tooling such as iwyu work much better on our code.
The most important change is getting rid of the manager.h include in
unit.h which is possible thanks to the previous commits. We also move
the OOMPolicy and StatusType enums to unit.h to remove the need for
other unit headers to include manager.h to get access to these enums.
The method is deprecated since 64f173324e
(v257) and announced that it will be removed in v258.
Let's remove it now.
This effectively reverts 84c01612de.
Admittedly, some of our glyphs _are_ special, e.g. "O=" for SPECIAL_GLYPH_TOUCH ;)
But we don't need this in the name. The very long names make some invocations
very wordy, e.g. special_glyph(SPECIAL_GLYPH_SLIGHTLY_UNHAPPY_SMILEY).
Also, I want to add GLYPH_SPACE, which is not special at all.
When running unprivileged containers, we run into a scenario where an
unpriv owned cgroup has a subcgroup delegated to another user (i.e. the
container's own UIDs). When the owner of that cgroup dies without
cleaning it up then the unpriv service manager might encounter a cgroup
it cannot delete anymore.
Let's address that: let's expose a method call on the service manager
(primarly in PID1) that can be used to delete a subcgroup of a unit one
owns. This would then allow the unpriv service manager to ask the priv
service manager to get rid of such a cgroup.
This commit only adds the method call, the next commit then adds the
code that makes use of this.
unit_file_add_dependency() asserts, so check before calling it that the
type is expected, or return EINVAL to the caller.
root@localhost:~# busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager AddDependencyUnitFiles "asssbb" 0 uwhatm8 After 1 1
Broadcast message from systemd-journald@localhost (Mon 2025-01-06 18:12:14 UTC):
systemd[1]: Caught <ABRT>, from our own process.
Fixes https://github.com/systemd/systemd/issues/35882
Luca BoccassiandMichal Koutný
Luca Boccassi
Michal Sekletar
Lennart Poettering
Simon Lucido
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
Michael Vogt
Daan De Meyer
Nikolas Kyx
Mike Yuan
Franck Bui
Yu Watanabe
Daan De Meyer
Lennart Poettering
Grimmauld
Jelle van der Waa
Zbigniew Jędrzejewski-Szmek