almost all code in namespace.c only logs at debug level as it is
"library-like" code. But there are some outliers. Adjust them to match
the rest of the code
(Well, there are some left)
frankly, the log message shouldn't be there at all, but the error path
be propagated up, with a recognizable error code. But apparently this is
important to @bluca.
So far we calculated exactly how many mounts we will generate, which is
a bit fragile, and easy to get wrong.
Let's normalize this, and grow the array of mounts as we need.
Various other modernizations while we are at it, such as FOREACH_ARRAY
usage, or `_cleanup_` usage.
UKIs may be loaded in a way, that there can not be a device handle to
the filesystem, that contains the image, for example when using a
bootloader to load the image from a partition with a file system that is
not supported by the firmware.
With the current systemd stub, this causes a failed assertion, because
stub gets passed a NULL DeviceHandle and FilePath. Inserting two
explicit checks enables proper boot even in this case.
Fixes: #29331
According to RFC 6762 section 8, an mDNS responder is supposed to announce its
records after probing.
Currently, there is a check in dns_scope_announce which returns if there are any
pending transactions. This prevents announcements from being sent out even if there
are pending non-probe transactions.
To fix this, return only if there are active probe transactions.
Before this we'd fail with a complaint that PIDFDs is not supported by
the service manager. Add some compat support by falling back to classic
numeric PIDs in that case.
When --boot is set, and --keep-unit is not, set CoredumpReceive=yes on
the scope allocated for the container. When --keep-unit is set, nspawn
does not allocate the container's unit, so the existing unit needs to
configure this setting itself.
Since systemd-nspawn@.service sets --boot and --keep-unit, add
CoredumpReceives=yes to that unit.
If a process crashes within a container, try and forward the coredump to
that container. To do this, check if the crashing process is in a
different pidns, and if so, find the PID of the namespace leader. We
only proceed with forwarding if that PID belongs to a cgroup that is
descendant of another cgroup with user.delegate=1 and
user.coredump_receive=1 (i.e. Delegate=yes and CoredumpReceive=yes).
If we proceed, attach to the namespaces of the leader, and send the
coredump to systemd-coredump.socket in the container. Before this is
done, we need to translate the PID, UID, and GID, and also re-gather
procfs metadata. Translate the PID, UID, and GID to the perspective of
the container by sending an SCM_CREDENTIALS message over a socket pair
from the original systemd-coredump process, to the process forked in the
container.
If we cannot successfully forward the coredump, fallback to the current
behavior so that there is still a record of the crash on the host.
For a given PID and namespace type, this helper function gives the PID
of the leader of the namespace containing the given PID. Use this in
systemd-coredump instead of using the existing get_mount_namespace_leader.
This helper will be used again in a later commit.
For convenience, store the crashing process's UID and GID in Context (as
uid_t and gid_t, respectively), as is currently done for the PID. This
means we can just parse the UID/GID once in save_context(), and use
those values in other places.
This is just re-factoring, and is a preparation commit for container
support.
This setting indicates that the given unit wants to receive coredumps
for processes that crash within the cgroup of this unit. This setting
requires that Delegate= is also true, and therefore is only available
where Delegate= is available.
This will be used by systemd-coredump to support forwarding coredumps to
containers.
Before this PR, if m->varlink_server is not yet set up during
deserialization, we call manager_setup_varlink_server rather than
manager_varlink_init, the former of which doesn't setup varlink
addresses, but only binds to methods. This results in that
newly-added varlink addresses not getting created if deserialization
takes place.
Therefore, let's switch to manager_varlink_init, and add some
sanity checks to it in order to prevent listening on the same
address twice.
Fixes#29373
Replaces #29421
As systemd-journal-upload deals mostly with remote servers, add
some failsafes to its unit to restart on failures.
```
[Service]
Restart=on-failure
RestartSteps=10
RestartMaxDelaySec=60
```
Lennart Poettering
Daan De Meyer
Lukas
Vishal Chillara Srinivas
Jan Janssen
Frantisek Sumsal
Luca Boccassi
Mike Yuan
Dan Streetman
Nick Rosbrook
Priit Laes