Log about missing executor at the emergency level, so the message always
makes it to the console - otherwise it won't get anywhere, since we
can't even start systemd-journald in that case.
Before:
Welcome to Arch Linux!
[ 5.202479] systemd[1]: Failed to allocate manager object: No such file or directory
[!!!!!!] Failed to allocate manager object.
[ 5.207741] systemd[1]: Freezing execution.
After:
Welcome to Arch Linux!
[ 5.279408] systemd[1]: Failed to open executor binary '/usr/lib/systemd/systemd-executor': No such file or directory
[ 5.290756] systemd[1]: Failed to allocate manager object: No such file or directory
[!!!!!!] Failed to allocate manager object.
[ 5.295919] systemd[1]: Freezing execution.
These are wrappers around getpwuid_r() and friends, and will allocate the
right-sized buffer for this call.
We so far had multiple implementations of a buffer allocation loop
around getpwuid_r() and friends, and they all suck in some way. Let's
clean this up and add a common implementation, and use it everywhere.
Also, be more careful with error numbers, in particular systematically
turn ENOENT into ENOSRCH (the former is what is returned if /etc/passwd
is absent, which we want to consider identical to user not existing,
which is ENOSRCH). We so far did this at some invocations, but not all.
There are some invocations of getpwuid() left in the codebase. We really
should fix those too, and have a single unified implementation of the
logic, but those are not as trivial to convert, so left for another
time.
Previously, path units would remain in the running state while their
target unit is deactivating. This left a window of time where the target
unit is no longer operational (i.e. it is busy deactivating/cleaning
up/etc) but the path unit would continue to ignore inotify events. In
short: any inotify event that occurs while the target unit deactivates
would be completely lost.
With this commit, the path will go back into a waiting state when the
target unit starts deactivating. This means that any inotify event that
occurs while the target unit deactivates will queue a start job.
Let's put the run queue really the last spot, as we should only start
doing more work if we really have nothing else to do anymore.
Let's move the service watchdog after the rewatch PID logic for similar
logic: it will possibly result in new jobs being enqueued to stop
things, and we should really have done all other work first.
We want to make sure we don't confuse the case "process started
successfully but then failed quickly" from the case "process failed to
start". Hence we need to make sure we take notice of Type=exec before we
bother with SIGCHLD.
Hence move EVENT_PRIORITY_EXEC_FD to the front. In fact, let's move it
even further up than SIGCHLD, i.e. before sd_notify() handling, so that
we don't end up processing service state change notifications before we
even considered that the service is properly started.
This also gives the cgroup OOM handling and the exec_fd handling
different priorities, to improve robustness of the system, we should act
quickly on OOM, and it doesn't matter if a service started succcessfully
if we have to act on OOM anyway.
This is based on Andrew Onyshchuk <andryk.rv@gmail.com> work here:
See: #30799Fixes: #28304
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
We had both uid-range.h and uid-alloc-range.h. The latter now contains helpers
like {uid,gid}_is_{system,dynamic,container}(), uid_for_system_journal(), so
the existing name is outdated. I think the uid-range.[ch] should stay separate
because it has a bunch of helpers for parsing and printing of uid ranges. So
let's rename as in $subject to better reflect the contents of the file and make
the two sets of files harder to confuse.
We don't "uncapitalize" parts of an already-capitalized name when concatenating
words. In particular, we had UidRange in basic/uid-range.h and UGIDAllocationRange
in basic/uid-alloc-range.h, which is annoying.
Some of these checks before bitwise operations are redundant and compilers
do not always recognize them, so let's simplify the code to make the intentions
clearer.
We already have specifiers that resolve to $XDG_STATE_HOME, and
$XDG_CONFIG_HOME. $XDG_DATA_HOME is in a similar vein.
It allows units belonging to the user service manager to correctly look
into ~/.local/share. I imagine this would be most useful inside of
condition checks (i.e. only run a service on session startup if some
data is not found in ~/.local/share) or in the inotify monitoring of a
.path unit
If PAMName= is used we'll spawn a PAM session for the service, and leave
a process around that closes the PAM session eventually. That process
must close the "exec_fd" that we use to implement Type=exec. After all
the logic relies on the fact that execve() will implicitly close the
exec_fd, and the EOF seen on it is hence indication for the service
manager that execve() has worked. But if we keep an fd open in the PAM
service process, then this is not going to work.
Hence close the fd explicitly so that it definitely doesn't stay pinned
in the child.
This commit introduces new D-Bus API, StartAuxiliaryScope(). It may be
used by services as part of the restart procedure. Service sends an
array of PID file descriptors corresponding to processes that are part
of the service and must continue running also after service restarts,
i.e. they haven't finished the job why they were spawned in the first
place (e.g. long running video transcoding job). Systemd creates new
scope unit for these processes and migrates them into it. Cgroup
properties of scope are copied from the service so it retains same
cgroup settings and limits as service had.
Global resource (whole system or root cg's (e.g. in a container)) is
also a well-defined limit for memory and tasks, take it into account
when calculating effective limits.
Users become perplexed when they run their workload in a unit with no
explicit limits configured (moreover, listing the limit property would
even show it's infinity) but they experience unexpected resource
limitation.
The memory and pid limits come as the most visible, therefore add new
unit read-only properties:
- EffectiveMemoryMax=,
- EffectiveMemoryHigh=,
- EffectiveTasksMax=.
These properties represent the most stringent limit systemd is aware of
for the given unit -- and that is typically(*) the effective value.
Implement the properties by simply traversing all parents in the
leaf-slice tree and picking the minimum value. Note that effective
limits are thus defined even for units that don't enable explicit
accounting (because of the hierarchy).
(*) The evasive case is when systemd runs in a cgroupns and cannot
reason about outer setup. Complete solution would need kernel support.
Yu Watanabe
Michal Koutný
Frantisek Sumsal
Lennart Poettering
Adrian Vovk
Mike Yuan
Zbigniew Jędrzejewski-Szmek
AtariDreams
Luca Boccassi
Michal Sekletar