This is a new syscall provided by the kernel used to implement faster
uprobes. It's not supposed to be called by userspace, but only by kernel
generated uprobe code.
It should be fine to allow this, as the kernel authenticates the
invocation itself, and we shouldn't break compat with things.
Note that this allowlisting is not sufficient to make ureprobe() work.
libseccomp must be tought the syscall too, but this can happen
independently.
Fixes: #34615
Let's always use systemctl reload to reexec and reload user managers
now that it always implies a reexec. This moves all the job management
logic to pid 1 instead of bash and reduces the complexity of the logic
as we remove systemd-run, pam and systemd-stdio-bridge from the equation.
Closes#28367 (but not really in the exact form, see below)
We have the problem of restarting all user manager instances
after upgrade. Current approaches involve systemctl kill
with SIGRTMIN+25, which is async and feels rather ugly [1][2];
or systemctl --machine=user@ --user, which requires entering
each user session. Neither is particularly elegant.
Instead, let's just signal daemon-reexec when user@.service
is reloaded from system manager. Our long goal of dropping
daemon-reload in favor of reexec (see TODO) is unlikely to happen
due to user dbus restrictions, but here the synchronization
is done via READY=1.
[1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/main/systemd.install?ref_type=heads#L37
[2] https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.postinst#L24#28367 would not really work for us now I come to think about it,
because all processes will be reparented to pid1 as soon as
original user manager process exits. This alternative approach
seems good enough for our use case.
This field indicates whether READY=1 has been sent to
the service manager/supervisor. Whenever we reload/reexec/soft-reboot,
manager_send_reloading() always resets it to false first,
so that READY=1 is sent after reloading finishes. Hence
we utterly get "false" at all times. Kill it.
This effectively reverts 37d15cd132.
The offending commit wrongly assumed that the second READY=1
notification is for system scope only, but it also serves the purpose
of flushing out previous STATUS= containing user unit job status.
Tools such as lsblk which query the udev database instead of probing
devices directly fail when run on ublk devices. For instance, in the
following commands, the partition type is missing, despite the fact that
/dev/ublkb0 was just partitioned with a single Linux filesystem type
partition.
$ lsblk /dev/ublkb0
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
ublkb0 259:0 0 31.3G 0 disk
└─ublkb0p1 259:1 0 31.2G 0 part
$ lsblk -o pkname,parttype /dev/ublkb0
PKNAME PARTTYPE
ublkb0
This happens because ublk devices are missing from a couple of
whitelists in the udev rules which are responsible for populating the
database with the data lsblk is looking for. Add the ublk devices to
these whitelists.
The annotation about omittance is meant to be about the `RANDOM` string.
However, the current formatting makes it look like the entire naming
scheme is optional. Fix this.
- use uint8_t, uint16_t, and so on, rather than unsigned char, unsigned
short, and so on, respectively,
- rename output parameters to ret or ret_xyz,
- add several missing assertions.
The documentation claimed that ExecStartPre=/ExecStartPost= accepts
multiple command lines, in contrast to ExecStart=. This is half an
untruth, because ExecStart= allows that too – as long as Type=oneshot is
set.
Hence, reword this a bit, and do not emphasize the contrast.
Prompted by: #34570
Even though we can get the existence of delayed action through
PreparingForShutdownWithMetadata property or friends, for consistency
with CancelScheduledShutdown() method, it is better to also provide the
information through ScheduledShutdown property.
Teaches systemd-stub how to load additional initrds from addon files.
This is very similar to the support for .ucode sections in addon files,
but with different ordering. Initrds from addons have a chance to
overwrite files from the base initrd in the UKI.