It's hard to oversee the assigned processing priorities of the various
event sources we have. Let's unify them in a table (an enum), where we
can have a single consisten look at them, and then reference the table
entries by expressive symbols.
This doesn#t change behaviour in any way, it just gives each priority a
nice label, but doesn't change any of the priorities.
Prompted by: #30799
* Use a unified struct to store accounting fields/suffixes
* Use strextendf_with_separator where appropriate
* Don't mix stack and heap allocation for one iovec array
If a unit is running in an image and wants to survive a soft-reboot,
then it can't be deactivated by the storage of the image going away.
Relax the dependency to a Wants=. Access to the image is not needed
when the unit is running anyway, so downgrade to Wants=.
This is the equivalent of RequiresMountsFor=, but adds Wants= instead
of Requires=. It will be useful for example for the autogenerated
systemd-cryptsetup units.
Fixes https://github.com/systemd/systemd/issues/11646
The only way this could be called with an invalid value would be if
somebody forgot to initialize unit type. In such cases, it's better to
fail hard immediately.
Those functions take a pointer to a timestamp and return a timestamp pointer,
so the reader would be justified to think that those are just getters. Rename
them to avoid confusion.
In 0531bded79 ("core: include peak memory in unit_log_resources()") new log
messages where added, however the size of the according arrays to hold the
messages was not adjusted.
Fixes: 0531bded79 ("core: include peak memory in unit_log_resources()")
Linux's Control Group v2 interfaces exposes memory.peak, which contains the
"max memory usage recorded for the cgroup and its descendants since the
creation of the cgroup."
This commit adds a new property "MemoryPeak" for units and makes "systemctl
show" display this value if it is available.
Fixes#29878.
Signed-off-by: Florian Schmaus <flo@geekplace.eu>
Sometimes it makes sense to hard kill a client if we die. Let's hence
add a third FORK_DEATHSIG flag for this purpose: FORK_DEATHSIG_SIGKILL.
To make things less confusing this also renames FORK_DEATHSIG to
FORK_DEATHSIG_SIGTERM to make clear it sends SIGTERM. We already had
FORK_DEATHSIG_SIGINT, hence this makes things nicely symmetric.
A bunch of users are switched over for FORK_DEATHSIG_SIGKILL where we
know it's safe to abort things abruptly. This should make some kernel
cases more robust, since we cannot get confused by signal masks or such.
While we are at it, also fix a bunch of bugs where we didn't take
FORK_DEATHSIG_SIGINT into account in safe_fork()
This is preparation for #28891, which adds a bunch more helpers around
"struct iovec", at which point this really deserves its own .c/.h file.
The idea is that we sooner or later can consider "struct iovec" as an
entirely generic mechanism to reference some binary blob, and is the
go-to type for this purpose whenever we need one.
This simply checks if the specified PidRef refers to the process we are
running in.
(In case you wonder why this is not a static inline: to avoid cyclic
header inclusion problems between pidref.h + process-util.h)
We generally prefer dealing with parsed data instead of original
strings, do so for the "rwm" strings too. We have to convert this to
flags for the primary backend implementation (BPF) anyway, hence we
can do this early to have simpler, shorter and more normalized code.
Currently we spawn services by forking a child process, doing a bunch
of work, and then exec'ing the service executable.
There are some advantages to this approach:
- quick: we immediately have access to all the enourmous amount of
state simply by virtue of sharing the memory with the parent
- easy to refactor and add features
- part of the same binary, will never be out of sync
There are however significant drawbacks:
- doing work after fork and before exec is against glibc's supported
case for several APIs we call
- copy-on-write trap: anytime any memory is touched in either parent
or child, a copy of that page will be triggered
- memory footprint of the child process will be memory footprint of
PID1, but using the cgroup memory limits of the unit
The last issue is especially problematic on resource constrained
systems where hard memory caps are enforced and swap is not allowed.
As soon as PID1 is under load, with no page out due to no swap, and a
service with a low MemoryMax= tries to start, hilarity ensues.
Add a new systemd-executor binary, that is able to receive all the
required state via memfd, deserialize it, prepare the appropriate
data structures and call exec_child.
Use posix_spawn which uses CLONE_VM + CLONE_VFORK, to ensure there is
no copy-on-write (same address space will be used, and parent process
will be frozen, until exec).
The sd-executor binary is pinned by FD on startup, so that we can
guarantee there will be no incompatibilities during upgrades.
Yu Watanabe
Lennart Poettering
Mike Yuan
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Florian Schmaus
Frantisek Sumsal
Daan De Meyer