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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Oftentimes it is useful to allow the per-service fd store to survive
longer than for a restart. This is useful in various scenarios:
1. An fd to some security relevant object needs to be stashed somewhere,
that should not be cleaned automatically, because the security
enforcement would be dropped then.
2. A user namespace fd should be allocated on first invocation and be
kept around until the user logs out (i.e. systemd --user ends), á la
#16328 (This does not implement what #16318 asks for, but should
solve the use-case discussed there.)
3. There's interest in allow a concept of "userspace reboots" where the
kernel stays running, and userspace is swapped out (i.e. all services
exit, and the rootfs transitioned into a new version of it) while
keeping some select resources pinned, very similar to how we
implement a switch root. Thus it is useful to allow services to exit,
while leaving their fds around till the very end.
This is exposed through a new FileDescriptorStorePreserve= setting that
is closely modelled after RuntimeDirectoryPreserve= (in fact it reused
the same internal type), since we want similar behaviour in the end, and
quite often they probably want to be used together.
Let's normalize how we release service resources, i.e. the three types
of fds we maintain for each service:
1. the fdstore
2. the socket fd for per-connection socket activated services
3. stdin/stdout/stderr
The generic service_release_resources() hook now calls into
service_release_fd_store() + service_close_socket_fd()
service_release_stdio_fd() one after the other, releasing them all for
the generic "release_resources" infra of the unit lifecycle.
We do no longer close the socket fd from service_set_state(), moving
this exclusively into service_release_resources(), so that all fds are
closed the same way.
The per-unit-type release_resources() hook (most prominent use: to
release a service unit's fdstore once a unit is entirely dead and has no
jobs more) was currently invoked as part of unit_check_gc(), whose
primary purpose is to determine if a unit should be GC'ed. This was
always a bit ugly, as release_resources() changes state of the unit,
while unit_check_gc() is otherwise (and was before release_resources()
was added) a "passive" function that just checks for a couple of
conditions.
unit_check_gc() is called at various places, including when we wonder if
we should add a unit to the gc queue, and then again when we take it out
of the gc queue to dtermine whether to really gc it now. The fact that
these checks have side effects so far wasn't too problematic, as the
state changes (primarily: that services would empty their fdstores) were
relatively limited and scope.
A later patch in this series is supposed to extend the service state
engine with a separate state distinct from SERVICE_DEAD that is very
much like it but indicates that the service still has active resources
(specifically the fdstore). For cases like that the releasing of the
fdstore would result in state changes (as we'd then return to a classic
SERVICE_DEAD state). And this is where the fact that the
release_resources() is called as side-effect becomes problematic: it
would mean that unit state changes would instantly propagate to state
changes elsewhere, though we usually want this to be done through the
run queue for coalescing and avoidance of recursion.
Hence, let's clean this up: let's move the release_resources() logic
into a queue of its own, and then enqueue items into it from the general
state change notification handle in unit_notify().
Since da6053d0a7 this is a size_t, not an
unsigned. The difference doesn't matter on LE archs, but it matters on
BE (i.e. s390x), since we'll return entirely nonsensical data.
Let's fix that.
Follow-up-for: da6053d0a7
An embarassing bug introduced in 2018... That made me scratch my head
for way too long, as it made #27135 fail on s390x while it passed
everywhere else.
Correct what appears to be a copy/paste error in config_parse_exec_coredump_filter that is preventing the coredump_filter setting from working correctly.
/bin/login is shipped in util-linux, however, systemd.spec on Fedora has
"Requires: (util-linux-core or util-linux)". If the dependency is
fulfilled just by installation of util-linux-core then users won't be
able to log in into the container after it boots. Let's add util-linux
package to the package list so that /bin/login is always present.
Let's honour the flag if it is set, just to be safe.
(This only handles the case for the writing side: whenever the client
code hands us a json object with the flag set we'll honour it till the
it's out of reach for us. This does *not* handle the reading side, which
is left for a later patch once needed. We probably should add a
per-connection flag that simply globally enables the sensitive logic for
all messages coming in on a specific varlink conneciton.)
Let's add infrastructure to implement fd passing in varlink, when used
over AF_UNIX.
This will optionally associate one or more fds with a message sent via
varlink and deliver it to the server.
Some minor refactoring. This adds a helper call whose only job is to
unref the JSON object of the currently processed incoming message.
This doesn't make too much sense on its own, given this just replaces
one line by another. However, in a later patch when we'll add fd passing
we'll extend the function to also destroy associated fds, and then it
will start to make more sense.
So far, if we do a synchronous varlink call from the client side via
varlink_call(), we'll
move the returned json object from "v->current" into "v->reply", and
keep it referenced there until the next call. We then return a pointer
to it. This ensures that the json object remains valid between two
varlink_call() invocations.
But the thing is, we don't need a separate field for that, we can just
leave the data in "v->current". This means VARLINK_IDLE_CLIENT state
will be permitted with and without v->current initialized. Initially,
after connection setup it will be set to NULL, but after the first
varlink_call() it will be set to the most recent response, pinning it
into memory.
When running in a container, we can propagate the exit status of
pid1 as usual via the process exit status. This is not possible
when running in a VM. Instead, let's send EXIT_STATUS=%i via the
notify socket if one is configured. The user running the VM can then
pick up the exit status from the notify socket after the VM has shut
down.
systemd-nspawn now optionally supports colon-separated pair of
host interface name and container interface name for --network-macvlan, --network-ipvlan and --network-interface options.
Also supported in .nspawn configuration files (i.e Interface=, MACVLAN=, IPVLAN= parameters).
man page changed for ntwk interface naming
Neither of the callers of bus_deserialize_and_dump_unit_file_changes()
touches the changes array, so let's simplify things and keep it internal
to the function.
Stripping the binaries in the test images makes potential stack straces
quite useless, so let's drop the stripping stuff to make test fails a bit
more developer friendly.
Related: https://github.com/systemd/systemd-centos-ci/pull/616
On x86 EFI follows the windows ABI, which expects 8-byte aligned long
long. The x86 sysv ELF ABI expects them to be 8-byte aligned when used
alone, but 4-byte aligned when they appear inside of structs:
struct S {
int i;
long long ll;
};
// _Static_assert(sizeof(struct S) == 12, "x86 sysv ABI");
_Static_assert(sizeof(struct S) == 16, "EFI/MS ABI");
To get the behavior we need when building with sysv ELF ABI we need to
pass '-malign-double' to the compiler as done by EDK2.
This in turn will make ubsan unhappy as the stack may not be properly
aligned on entry, so we have to tell the compiler explicitly to re-align
the stack on entry to efi_main.
This fixes loading EFI drivers on x86 that were previously always
rejected as the EFI_LOADED_IMAGE_PROTOCOL had a wrong memory layout.
See also: https://github.com/rhboot/shim/pull/516
