IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Protect{Home,System,Proc,Subset}= are not booleans, so make sure we use
the intended value instead of just true/false.
See: https://github.com/systemd/systemd/pull/29552
Follow-up to: 79d956d
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
```
No functional changes, only moving code that is only needed in
exec_invoke, and adding new dependencies for seccomp/selinux/apparmor/pam
in meson for the sd-executor binary.
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.
If we encounter an empty struct in the varlink IDL it could also be an
empty enum. Refuse this to avoid the ambiguity.
The spec doesn't cover this case clearly, hence let's better be on the
safe side and refuse it rather than making a decision what it means.
