Backward incompatible change to avoid returning 'skipped' if a condition causes
a job activation to be skipped when using StartUnitWithFlags().
Job results are broadcasted, so it is theoretically possible that existing
software could get confused if they see this result.
Replaces https://github.com/systemd/systemd/pull/22369
The only piece missing was to somehow make /proc appear in the
new user+mount namespace. It is not possible to mount a new
/proc instance, not even with hidepid=invisible,subset=pid, in
a user namespace unless a PID namespace is created too (and also
at the same time as the other namespaces, it is not possible to
mount a new /proc in a child process that creates a PID namespace
forked from a parent that created a user+mount namespace, it has
to happen at the same time).
Use the host's /proc with a bind-mount as a fallback for this
case. User session services would already run with it, so
nothing is lost.
The function has nothing to do with any Manager object, hence drop that
from the name. And it actually looks something up by handle *action* not
by *handle*, hence the old name was a bit misnomer. Let's call it
handle_action_lookup(), as it queries handle action metainfo for a
handle action.
Also, let's make sure it behaves more like our usual functions that
lookup some fixed data from some enum value/int: let's return NULL if we
don't find it.
It stores meta-info about various HandleActions, hence let's name it
after that. The fact that it can be seen as stored inside some form of a
table is an implementation detail of logind-action.c, and should not
leak into other modules, hence let's focus on what it is, not how it is
stored.
The old macro will double evaluation and has no protection against
operator precedence issues. Let's fix that by using an inline func
instead, which also gives us typesafety.
RANDOM_BLOCK has existed for a long time, but RANDOM_ALLOW_INSECURE was
added more recently, leading to an awkward relationship between the two.
It turns out that only one, RANDOM_BLOCK, is needed.
RANDOM_BLOCK means return cryptographically secure numbers no matter
what. If it's not set, it means try to do that, but if it fails, fall
back to using unseeded randomness.
This part of falling back to unseeded randomness is the intent of
GRND_INSECURE, which is what RANDOM_ALLOW_INSECURE previously aliased.
Rather than having an additional flag for that, it makes more sense to
just use it whenever RANDOM_BLOCK is not set. This saves us the overhead
of having to open up /dev/urandom.
Additionally, when getrandom returns too little data, but not zero data,
we currently fall back to using /dev/urandom if RANDOM_BLOCK is not set.
This doesn't quite make sense, because if getrandom returned seeded data
once, then it will forever after return the same thing as whatever
/dev/urandom does. So in that case, we should just loop again.
Since there's never really a time where /dev/urandom is able to return
some easily but more with difficulty, we can also get rid of
RANDOM_EXTEND_WITH_PSEUDO. Once the RNG is initialized, bytes
should just flow normally.
This also makes RANDOM_MAY_FAIL obsolete, because the only case this ran
was where we'd fall back to /dev/urandom on old kernels and return
GRND_INSECURE bytes on new kernels. So also get rid of that flag.
Finally, since we're always able to use GRND_INSECURE on newer kernels,
and we only fall back to /dev/urandom on older kernels, also only fall
back to using RDRAND on those older kernels. There, the only reason to
have RDRAND is to avoid a kmsg entry about unseeded randomness.
The result of this commit is that we now cascade like this:
- Use getrandom(0) if RANDOM_BLOCK.
- Use getrandom(GRND_INSECURE) if !RANDOM_BLOCK.
- Use /dev/urandom if !RANDOM_BLOCK and no GRND_INSECURE support.
- Use /dev/urandom if no getrandom() support.
- Use RDRAND if we would use /dev/urandom for any of the above reasons
and RANDOM_ALLOW_RDRAND is set.
On Ubuntu CI on ppc64el, the test randomly fails when /run/udev is not
synced before checking its contents (see #22357). But /run/udev is a
tmpfs and fsync on tmpfs is noop (see `struct shmem_file_operations` in
mm/shmem.c of the kernel), hence, it is not necessary to call fsync on
/run/udev in general. This should be a testing emvironment issue (I
guess it is an issue on nested KVM on ppc64el), instead of an issue on
udev.
C.f. #22357.
Fixes#21603.
This can help users to figure out what makes systemd freeze.
1. Someone kills systemd accidentally, then the sender_pid won't be 1;
2. systemd triggers segfault or assert, then the sender_pid will be 1;
When writing docs for SD_BUS_VTABLE_CAPABILITY, I noticed that we have one use
of SD_BUS_VTABLE_CAPABILITY(CAP_SYS_ADMIN) in the tree. This is the default, so
it's not very useful to specify it. But if we're touching that, I think it's
better to use mac + polkit for this like for everything else.
We don't have a very good category for this, but I don't think it makes sense
to add a new one. I just reused the same as other similar calls.
Some SCSI tape devices use the same device ID (NAA registered device
designator) for the SCSI tape changer device and the first actual tape
device. For example, this one:
https://docs.oracle.com/en/storage/tape-storage/storagetek-sl150-modular-tape-library/slofs/bridged-tape-drives.html
You must connect the bridged drive to an HBA supporting multiple
LUNs (also referred to as LUN scanning). The SL150 Library uses a
single SCSI ID and two logical unit numbers (LUN). LUN 0 controls
the tape drive and LUN 1 which is configured as a SCSI medium
changer device controls the robotics. Data is sent to the remaining
LUN on the bridged drive or to LUNs on the other, unbridged drives
in the partition, all of which are configured as SCSI
sequential-access (tape) devices.
This may lead to errors because /dev/tape/by-id symlinks may sometimes
point to the st device representing the tape, and sometimes to the sg
device representing the changer.
Fix this by assigning an increased priority to the tape device, and creating
a separate -changer link for the SCSI tape changer.
Co-developed-by: Martin Wilck <mwilck@suse.com>
In some BIOSes, the "Number of slots or sockets available for Memory
Devices in this array" is incorrectly set to the number of memory array
that's populated.
Work-around this problem by outputting the number of sockets after
having parsed them so that consumers of this data can carry on expecting
an accurate number in this property.
This fixes the number of memory slots advertised for the HP Z600.
See https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1686
The complaint was that the output array was used for two kinds of data, and the
input flag decided whether this extra data should be included. The flag is
removed, and instead the old method is changed to include the data always as
a separate parameter.
This breaks backward compatibility, but the old method is effectively broken
and does not appear to be used yet, at least in open source code, by
searching on codesearch.debian.net and github.com.
Fixes#22404.
Co-authored-by: Luca Boccassi <bluca@debian.org>
IIUC, pipefail doesn't matter for a sequence of commands joined with &&, and we
don't have any pipes. And such a failing expression also does not trigger an
exit, so the set +e/set -e were noops.
The brightness control key (Fn+F7 Fn+F8) and touchpad toggle key (Fn + Space) do not work on the NEC VersaPro VG-S laptop. Add the keycode to fix the problem.
Make sure our RPM macros work as intended. Based on the original PR
(#16464) by Mikhail Novosyolov.
Co-authored-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
I think the current behaviour is stupid: 'x-systemd.automount,noauto' should
mean that we create the units, but don't add .mount or .automount to any targets.
Instead, we completely ignore 'noauto'. But let's at least describe the
implementation.
Text suggested by dpartrid in the bug.
Fixes#21040.
A description of SD_BUS_VTABLE_CAPABILITY is added, and the discussion
on SD_BUS_VTABLE_UNPRIVILEGED in expanded. I think it would be nice
to add longer description of how access is checked (maybe in sd-bus(3)),
but I'm leaving that for later. I think the text that was added here
describes everything, even if tersely.
Fixes#21882.
docbook would convert the newline to a space before the first argument:
SD_BUS_METHOD_WITH_ARGS( member, args, result, handler)
And we need each item in a separate <para>, otherwise they'll all be in
one line.
Luca Boccassi
Yu Watanabe
licunlong
Temuri Doghonadze
Lennart Poettering
Jason A. Donenfeld
Laura Barcziova
Zbigniew Jędrzejewski-Szmek
David Bond
tawefogo
Ludwig Nussel
Frantisek Sumsal
Bastien Nocera
Daan De Meyer
4piu
David Tardon
Alfonso Sánchez-Beato