Let's introduce these for the following two reasons:
- Using them makes sure the parameter names match between declaration
and definition (if both use the corresponding macros).
- They make sure developers can't forget the _const_ and _pure_
attributes for the declarations.
This commit also includes some include sorting fixes
There are multiple ways to encode ANSI ST, and we generally prefer ESC \
for it, for reasons explained in terminal-util.h. Hence, let's actually
follow this rule in the terminal reset logic, and use the ANSI_ST macro.
This will change the byte sequence generated (as it means we use ESC \
rather than BEL), but it doesn't change behaviour, as the two sequences
should be equivalent.
This introduces RECURSE_DIR_UNLINK + RECURSE_DIR_UNLINK_GRACEFUL as new
return values for recurse_dir() callbacks. If either is returned the
inode currently processed will be removed and iteration continues with
the next item.
This is useful to have in the recurse_dir() mechanism itself (rather
than implement in the callback itself), due to ordering: we want to pin
the inodes via an fd while calling the callbacks, but we have to close
it before removal of the inodes. By moving this into the recurse_dir()
infra, we can implement this easily.
Allow CPUSchedulingPolicy to be set to "ext". SCHED_EXT is a new
scheduling policy in Linux v6.12 that allows processes to be scheduled
using custom BPF schedulers instead of the default in-kernel ones.
Selectively setting the SCHED_EXT policy is useful for systems running
in "partial mode" where not all processes are run using a custom
scheduler.
Fallback to SCHED_OTHER and print an error message for systems where
SCHED_EXT isn't available.
Note that we still have to block SIGCHLD so that
we can be certain the process is not reaped before
we get the pidfd to it. safe_fork() and friends are
used in libsystemd where we don't control how the
SIGCHLD signal is configured. Specifically, kernel
autoreaping could be enabled which is why we have
to block SIGCHLD until we get the pidfd so that the
kernel cannot autoreap the process before we get
the pidfd.
First, don't require blocking SIGCHLD for WEXITED. We watch for WEXITED
via pidfd instead of signalfd, so no need to insist on blocking SIGCHLD
anymore if we're only watching for WEXITED.
Second, do a proper check to see if the kernel autoreaping logic is
enabled. That has nothing to do with SIGCHLD being blocked for the current
thread or not. Instead, the kernel autoreaping logic is enabled either if
the disposition is set to SIG_IGN or if the SA_NOCLDWAIT flag is enabled.
* Specifying all 3 of FORK_DEATHSIG_SIG{KILL,TERM,INT} for
the middle man makes zero sense. Use SIGKILL only.
* Make sure operations on except_fds work sensibly - close/pack/
de-ocloexecify fds only in the second level, so that the namespace
fds remain usable across first safe_fork().
* Fire FORK_NEW_*NS after attaching to the desired namespaces,
not already in the outer process.
* Insist on PDEATHSIG being enabled to ensure propagation of killing.
* Suppress more redundant flags.
This allows us to query the window size without moving the cursor. We have
various reports about the cursor being in an unexpected position and/or state.
Closes https://github.com/systemd/systemd/issues/37526.
While blocking dlopen() in child generally makes sense, it does
also lead to misery - in the very case of extension/cred refreshing
it then enforces loading of libcryptsetup/libacl in pid1, which
are otherwise never used. Let's add a flag to opt out hence, but
still prohibit it in namespace_fork/enter().
manager_varlink_init_resolve_hook and manager_varlink_init_userdb are very
similar, but one didn't set a description and the other one had an error
message which didn't print the offending path.
Define constants for the paths, and also change other similar constants
to have slightly shorter names. (It's an "address" and "path", but we don't
need to have both parts in the name, esp. that it makes the name very long.)
Latest glibc uses _Generic to have strstr() and other functions return
const char* or char* based on whether the input is a const char* or a
char*. This causes build failures as we previously always expected a
char*.
Let's fix the compilation failures and add our own macros similar to
glibc's to have string functions that return a mutable or const pointer
depending on the input.
Latest glibc uses _Generic to have strstr() and other functions return
const char* or char* based on whether the input is a const char* or a
char*. This causes build failures as we previously always expected a char*.
Let's fix the compilation failures and add our own macros similar to glibc's
to have string functions that return a mutable or const pointer depending on
the input.
When in --empower mode, all created files will be owned by the current
user, which could be problematic when creating files outside of the
current user's home directory, as other processes running as the same
user would be able to edit those files.
While this is a bit of an edge case since users already have to go through
the effort of writing --empower to indicate they want a privileged session
as the current user, it's not unphatomable to think they could start an
empowered session which they later return to and continue using. Currently,
it's not easy to differentiate a regular run0 session and an empowered session
at a glance, so users might think they're using a regular run0 session when
they're actually using an empowered session.
To address this problem, let's give empowered session their own identify, by
making the background orange, using the pumpkin emoji as the shell prompt
prefix and giving them an orange circle as the PTY title.
Some of the functions were ignoring failure in cleanup, others weren't. If we
got a reply, it's better to use it, so ignore failures in cleanup everywhere.
This moves the open call earlier, so that we do any state-changing operations
if we actually managed to open the nonblocking fd. The code is easier to follow
this way and might be more robust.
Suprisingly, this fixes https://github.com/systemd/systemd/issues/39055: it
seems that run0 chowns /dev/stdin (in my case /dev/pts/0) to root:root, and the
second run0 can read and write stdin/stdout throught the already-open fds,
but fd_reopen fails.
Fixes https://github.com/systemd/systemd/issues/39055.
Daan De Meyer
Lennart Poettering
Jörg Behrmann
Luiz Amaral
Mike Yuan
Matt Fleming
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Yu Watanabe
Alexis-Emmanuel Haeringer
David Tardon