Previously, all queued events were discarded on exit, hence several
events might not be processed by udevd when it is restarted. Such
situation especially easily happens on switching root.
This makes queued events serialized on exit, and deserialized in the
next invocation. Hence, no events should be lost during restarting
udevd.
This is important with the several aspects. Basically
systemd-udev-trigger.service (re)triggers all devices anyway after
switching root, But the service may be disabled or modified by admin.
Moreover, the service produces only 'add' events, and thus the service
cannot cover events with other actions generated by the kernel during
switching root. Also, the userspace triggered events may not contain
some parameters compared with events triggered by the kernel.
ssh-generator and ssh-proxy are great features, it is very handy to be
able to do:
ssh vsock/1
But, because of the '/' used as a separator, scp and rsync don't
interpret 'vsock/<CID>' as a hostname, e.g.
$ scp /etc/machine-id vsock/2222:.
cp: cannot create regular file 'vsock/2222:.': No such file or directory
$ rsync /etc/machine-id vsock/2222:.
rsync: [Receiver] change_dir#3 "(...)/vsock" failed: No such file or directory (2)
rsync error: errors selecting input/output files, dirs (code 3) at main.c(829) [Receiver=3.4.1]
An alternative is to use ',' as separator, e.g.
$ scp /etc/machine-id vsock,2222:.
This is what is being suggested here. The names with '/' are kept not to
break anything here.
Others are possible: '%', '=', '#', '@', ':', etc. As mentioned in
commit 0abd510f7f ("ssh-proxy: add ssh ProxyCommand tool that can
connect to AF_UNIX + AF_VSOCK sockets"), it is better to avoid ':' as it
is already taken by SSH itself when doing sftp, and "@" is already taken
for separating the user name. '#' will cause some issues with some
shells like ZSH when quotes are not used.
Otherwise, if already 'remove' uevent for the device is queued, then
the device node may not exist any more when 'udevadm wait' command succeeds.
Follow-up for 90941d458a.
bind9 9.21 removed the deprecated 'managed-keys', swap it with
'trust-anchors' if the version is 9.21 or newer
[ 20.654086] TEST-75-RESOLVED.sh[1217]: + delv -a /etc/bind.keys @ns1.unsigned.test signed.test
[ 20.654425] TEST-75-RESOLVED.sh[1218]: + tee /tmp/tmp.D4LNomAKqY
[ 20.672599] TEST-75-RESOLVED.sh[1218]: ;; /etc/bind.keys:1: option 'managed-keys' no longer exists
Otherwise, if a test in a spurious state, it consumes quite long time.
Let's fail earlier in such case.
This also drops an unnecessary calls of 'udevadm settle' in
testcase_nvme_basic() of TEST-64-UDEV-STORAGE.
The tests were failing, because the quota was not enforced.
It seems that we simply don't have privileges to set or display the quota.
The test is running priviled, so this is probably some SELinux:
TEST-46-HOMED.sh[117]: + /usr/lib/systemd/tests/unit-tests/manual/test-display-quota tmpfsquota /dev/shm /tmp
TEST-46-HOMED.sh[1103]: Lacking privileges to query UID quota on /dev/shm: Operation not permitted
TEST-46-HOMED.sh[1103]: Lacking privileges to query UID quota on /tmp: Operation not permitted
If we cannot display the quota, ignore the test results.
In a local run under mkosi, quota is shown and the tests pass. So this is something
about how the testing-farm:fedora-rawhide-x86_64 is configured.
The test fails in CI. My guess was this is because the enablement of quota on
/tmp and /dev/shm is independent. The former fs is mounted by systemd in the
host, while the latter is mounted in the initrd, so we can end up with quota
support on one but not the other, which is the situation I had on my laptop.
This wasn't actually the source of the problems in CI, but it's a reasonable
change to make anyway.
While at it, test both mountpoints separately.
14385s [ 66.896852] TEST-87-AUX-UTILS-VM.sh[3744]: + test -x /usr/lib/systemd/systemd-validatefs
14385s [ 66.898544] TEST-87-AUX-UTILS-VM.sh[3744]: + echo 'no systemd-validatefs'
14385s [ 66.899115] TEST-87-AUX-UTILS-VM.sh[3744]: no systemd-validatefs
14385s [ 66.899699] TEST-87-AUX-UTILS-VM.sh[3744]: + return
14385s [ 66.900189] TEST-87-AUX-UTILS-VM.sh[3744]: .//usr/lib/systemd/tests/testdata/units/TEST-87-AUX-UTILS-VM.validatefs.sh: line 13: return: can only `return' from a function or sourced script
Follow-up for 6e003d18bb
If the target dir is tmpfs and we run on old kernels we cannot extract
xattrs and the extracting will fail if there are any. hence add
-no-xattrs to the two remaining unsquashfs invocations that don't have
it.
(Also all other invocations across our test tree spell "-dest" instead
of "-d", hence do so here too.)
We enable nsdelegate for cgroupfs, and hence the kernel would
always refuse writes to /sys/fs/cgroup/cgroup.pressure and friends
regardless of whether the cgns is owned by userns:
https://github.com/torvalds/linux/blob/cb82ca153949c6204af793de24b18a04236e79fd/kernel/cgroup/cgroup.c#L4132
This currently works because the mountns (thus cgroupfs) remains
to be non-delegated and we're actually operating on the real root
cgroup.
It appears that cgroupfs generally doesn't care about userns,
so I'm yet to see a way to test this properly. Let's drop this for now,
to unblock fixes in the following commits.
Currently DelegateNamespaces= only works for services spawned by the
system manager. User managers will always unshare the user namespace
first even if they're running with CAP_SYS_ADMIN.
Let's add support for DelegateNamespaces= for user managers if they're
running with CAP_SYS_ADMIN. By default, we'll still delegate all namespaces
for user managers, but this can now be overridden by explicitly passing
DelegateNamespaces=.
If a user manager is running without CAP_SYS_ADMIN, the user manager is
still always unshared first just like before.
Lennart Poettering
Daan De Meyer
Yu Watanabe
Matthieu Baerts (NGI0)
Luca Boccassi
Mike Yuan
Luca Boccassi
Matteo Croce
Zbigniew Jędrzejewski-Szmek