Partially reverts commit b0d3095fd6.
While it is generally worthwhile for systemd to drop split-usr support,
these options are NOT about split-usr support. The universal location of
POSIX sh is always /bin/sh. Bash is pretty reasonably standardized there
too.
This happens irrespective of /bin being a symlink to /usr/bin.
Ramifications of this change include things like:
- portably running shell scripts that might run very nearly anywhere
- /etc/shells support
For standardization and compatibility reasons, these commands with these
paths need to be consistently found on any system, and thus distros make
sure this works, although even on split-usr systems /usr/bin/bash may be
a symlink to /bin/bash.
Embedding the *access path* of bash as /usr/bin/bash in systemd, for
example in libnss_systemd.so, means that login shells must agree with
systemd on how they invoke the shell. End result: users fail to login
because of access violations.
This cannot be fixed by "fixing PAM" because PAM does not follow
symlinks by design: one example is that it needs to treat rbash as
different from bash.
Fixes: https://bugs.gentoo.org/919749
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Tighten our VM check: whether we run in a VM is not enough to do
AF_VSOCK. We also need to check if we are run in a container, because if
we run in a container inside a VM then we should *not* do the AF_VSOCK
stuff, but leave the port free for the VM itself.
As discussed here:
https://github.com/systemd/systemd/pull/31544#issuecomment-1971455401
This makes it easier for people packaging kernel-install plugins
to get the path right.
E.g. https://src.fedoraproject.org/rpms/python-virt-firmware/pull-request/3
fixes an issue where %{_libdir}/kernel/install.d was used,
which gives incorrect results on 64-bit architectures.
%_kernel_install_dir will make this even easier.
It appears the build-api effort at
https://github.com/cgwalters/build-api hasn't really caught on.
systemd appears one of the very few projects actually supporting it.
It does confuse certain tools though. E.g. debhelper by finding a
configure script wrongly assumes this is an autoconf project and thus
needs to be told explicitly that this is in fact a Meson project [1].
Given that Meson is an established build system by now, it appears ok to
drop this compat layer, which will never be fully complete anyway.
[1] https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules?ref_type=heads#L281
- avoid stripping debug symbols and creating dbgsym packages
- avoid LTO, slows down build a lot
- avoid compressing packages, they are thrown out immediately after use
- avoid building udeb packages, not needed
let's make userspace verity signature checking optional. This adds a
dissection flag to enable the logic and patches through all our users to
enable it by default, thus effectively not changing anything from the
status quo ante. However, know we have a knob to turn this off in
certain scenarios.
The glibc API is behind the wrapper is called "secure_getenv()", hence
our wrapper really should keep the order too, otherwise things are just
too confusing.
Most of our kernel cmdline options use underscores as word separators in
kernel cmdline options, but there were some exceptions. Let's fix those,
and also use underscores.
Since our /proc/cmdline parsers don't distinguish between the two
characters anyway this should not break anything, but makes sure our own
codebase (and in particular docs and log messages) are internally
consistent.
Previously if a PTYForward instance had the window title set but no
background color set then it would crash in an assertion as
pty_forward_ansi_process didn't require both to be present.
systemd-vmspawn could get into this state if it failed to get the
terminal tint color.
Now any method that would have called background_color_sequence now
becomes just a NOP if the background color is not set.
This allows keeping the functionality to set window titles even if the
terminal doesn't support the background coloring.
Currently scan_background_color_response only accepts BEL (\x07) to end
a response, however some terminals (namely kitty in my case) will reply
with the string terminator (ST - https://en.wikipedia.org/wiki/ANSI_escape_code).
This commit changes the behaviour to now accept either ending.
Currently the return value 0 is not checked for, this indicates a
timeout and should be handled to prevent doing a blocking read on a file
descriptor with no data ready.
This effectively reverts 9175002864.
The retrans time field in RA message is for neighbor solicitation,
and the commit d4c8de21a0 makes the value
assigned to the correct sysctl property.
Let's deprecate the option, and drop the redundant functions.
Takes a list of CPU indices or ranges separated by either whitespace or commas. Alternatively,
takes the special value "all" in which will include all available CPUs in the mask.
CPU ranges are specified by the lower and upper CPU indices separated by a dash (e.g. "2-6").
This option may be specified more than once, in which case the specified CPU affinity masks are merged.
If an empty string is assigned, the mask is reset, all assignments prior to this will have no effect.
Defaults to unset and RPS CPU list is unchanged. To disable RPS when it was previously enabled, use the
special value "disable".
Currently, this will set CPU mask to all `rx` queue of matched device (if it has multiple queues).
The `/sys/class/net/<dev>/queues/rx-<n>/rps_cpus` only accept cpu bitmap mask in hexadecimal.
Fix: #30323
Yu Watanabe
Luca Boccassi
Eli Schwartz
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Ludwig Nussel
Frantisek Sumsal
Michael Biebl
Sam Leonard
Renjaya Raga Zenta