diff options
author | Luca Boccassi <bluca@debian.org> | 2024-04-29 17:14:12 +0200 |
---|---|---|
committer | Luca Boccassi <luca.boccassi@gmail.com> | 2024-08-29 13:48:55 +0200 |
commit | 5162829ec87df20c7af763bdf274735bf9e53552 (patch) | |
tree | 06798c199c0d140c076bc499d1c70633d4e2b70a /man/systemd.xml | |
parent | ukify: Skip test on architectures without UEFI (diff) | |
download | systemd-5162829ec87df20c7af763bdf274735bf9e53552.tar.xz systemd-5162829ec87df20c7af763bdf274735bf9e53552.zip |
core: do BindMount/MountImage operations in async control process
These operations might require slow I/O, and thus might block PID1's main
loop for an undeterminated amount of time. Instead of performing them
inline, fork a worker process and stash away the D-Bus message, and reply
once we get a SIGCHILD indicating they have completed. That way we don't
break compatibility and callers can continue to rely on the fact that when
they get the method reply the operation either succeeded or failed.
To keep backward compatibility, unlike reload control processes, these
are ran inside init.scope and not the target cgroup. Unlike ExecReload,
this is under our control and is not defined by the unit. This is necessary
because previously the operation also wasn't ran from the target cgroup,
so suddenly forking a copy-on-write copy of pid1 into the target cgroup
will make memory usage spike, and if there is a MemoryMax= or MemoryHigh=
set and the cgroup is already close to the limit, it will cause an OOM
kill, where previously it would have worked fine.
Diffstat (limited to 'man/systemd.xml')
-rw-r--r-- | man/systemd.xml | 34 |
1 files changed, 14 insertions, 20 deletions
diff --git a/man/systemd.xml b/man/systemd.xml index 58e76eecb2..ddd190093e 100644 --- a/man/systemd.xml +++ b/man/systemd.xml @@ -89,28 +89,22 @@ <refsect1> <title>Units</title> - <para>systemd provides a dependency system between various - entities called "units" of 11 different types. Units encapsulate - various objects that are relevant for system boot-up and - maintenance. The majority of units are configured in unit - configuration files, whose syntax and basic set of options is + <para>systemd provides a dependency system between various entities called "units" of 11 different + types. Units encapsulate various objects that are relevant for system boot-up and maintenance. The + majority of units are configured in unit configuration files, whose syntax and basic set of options is described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, - however some are created automatically from other configuration - files, dynamically from system state or programmatically at runtime. - Units may be "active" (meaning started, bound, plugged in, …, - depending on the unit type, see below), or "inactive" (meaning - stopped, unbound, unplugged, …), as well as in the process of - being activated or deactivated, i.e. between the two states (these - states are called "activating", "deactivating"). A special - "failed" state is available as well, which is very similar to - "inactive" and is entered when the service failed in some way - (process returned error code on exit, or crashed, an operation - timed out, or after too many restarts). If this state is entered, - the cause will be logged, for later reference. Note that the - various unit types may have a number of additional substates, - which are mapped to the five generalized unit states described - here.</para> + however some are created automatically from other configuration files, dynamically from system state or + programmatically at runtime. Units may be "active" (meaning started, bound, plugged in, …, depending on + the unit type, see below), or "inactive" (meaning stopped, unbound, unplugged, …), as well as in the + process of being activated or deactivated, i.e. between the two states (these states are called + "activating", "deactivating"). A special "failed" state is available as well, which is very similar to + "inactive" and is entered when the service failed in some way (process returned error code on exit, or + crashed, an operation timed out, or after too many restarts). If this state is entered, the cause will + be logged, for later reference. Units may also be in a special transient state for a time, to indicate + that some operation is being performed on them, before reverting to the previous state, such as + "maintenance", "reloading" or "refreshing". Note that the various unit types may have a number of + additional substates, which are mapped to the five generalized unit states described here.</para> <para>The following unit types are available:</para> |