This PidRef just track some data, but cannot be used for any active
operation.
Background: for https://github.com/systemd/systemd/pull/34703 it makes
sense to track explicitly if some PidRef is not a local one, so that we
never attempt to for example "kill a remote process" and thus
acccidentally hit the wrong process (i.e. a local one by the same PID).
let's rename the "_ts" flavour of these calls "_full" instead, exposing
the full functionality. And then keep two more minimal versions around:
one "_at" (which has the ts parameter suppressed, but keeps the dir_fd
one). And one without suffix (which supresses both).
Do the same for the label versions of these calls.
if a userdb service refuse a user/group name as invalid, let's turn this
into ESRCH client-side following that there definitely is no user/group
record for a completely invalid user/group name.
Replaces: #34558
Since the root directory was being suppressed to NULL, the subsequent
check would erroneously think that no working directory was specified.
This caused the default working directory to be applied instead.
- suppress unnecessary error messages, especially in loop and at_exit(),
- ensure the container service is stopped before restarting,
- do not send KILL signal, as garbages will remain, and disturb the next
invocation,
- drop unnecessary workaround of trying machine twice.
As another device may be created with the same device node while udevd
is processing the remove event of the previous owner of the device node.
This also adds comment why we skip watching device node on remove.
This is just paranoia, to ensure that we don't accidentally
initiate resume if the initrd is entered through soft-reboot
rather than the initial one for booting up.
soft-reboot allows switching into a different root/installation,
i.e. potentially invalidate settings from kernel cmdline and such.
Let's hence inform generators about soft-reboots.
The kernel resets the IPv6 MTU of an interface when its link MTU is changed.
But it seems the operation is asynchronous, and even when we detect that
the link MTU is changed, the IPv6 MTU may not be reset yet.
====
[ 2257.067613] systemd-networkd[447122]: veth99: MTU is changed: 1500 →1600 (min: 68, max: 65535)
[ 2257.067641] systemd-networkd[447122]: Setting '/proc/sys/net/ipv6/conf/veth99/mtu' to '1410'
[ 2257.067711] systemd-networkd[447122]: No change in value '1410', suppressing write
====
As you can see, even if the link MTU is changed to 1600, the IPv6 MTU is
unchanged (in this case, still 1410).
Lennart Poettering
Luca Boccassi
Bryan Gurney
Yu Watanabe
John A. Leuenhagen
Mike Yuan