systemd version the issue has been seen with
latest master
Used distribution
latest Arch Linux
Linux arch.localdomain 5.4.10-arch1-1 #1 SMP PREEMPT Thu, 09 Jan 2020 10:14:29 +0000 x86_64 GNU/Linux
During today's night the Arch Linux image got updated and with this update several test-execute subtests started failing, like this one:
exec-privatedevices-yes-capability-mknod.service: Passing 0 fds to service
exec-privatedevices-yes-capability-mknod.service: About to execute: /bin/sh -x -c '! capsh --print | grep cap_mknod'
exec-privatedevices-yes-capability-mknod.service: Forked /bin/sh as 8541
exec-privatedevices-yes-capability-mknod.service: Changed dead -> start
exec-privatedevices-yes-with-group.service: Control group is empty.
Applying namespace mount on /run/systemd/unit-root/dev
Failed to umount /run/systemd/unit-root/dev: Device or resource busy
Successfully unmounted /run/systemd/unit-root/dev/shm
Failed to umount /run/systemd/unit-root/dev: Device or resource busy
Successfully unmounted /run/systemd/unit-root/dev/pts
Failed to umount /run/systemd/unit-root/dev: Device or resource busy
Successfully unmounted /run/systemd/unit-root/dev/hugepages
Failed to umount /run/systemd/unit-root/dev: Device or resource busy
Successfully unmounted /run/systemd/unit-root/dev/mqueue
Successfully unmounted /run/systemd/unit-root/dev
Operating on architecture: x86
Operating on architecture: x32
Operating on architecture: x86-64
exec-privatedevices-yes-capability-mknod.service: Executing: /bin/sh -x -c '! capsh --print | grep cap_mknod'
+ capsh --print
+ grep cap_mknod
Received SIGCHLD from PID 8541 (sh).
Child 8541 (sh) died (code=exited, status=1/FAILURE)
exec-privatedevices-yes-capability-mknod.service: Failed to read oom_kill field of memory.events cgroup attribute: No such file or directory
exec-privatedevices-yes-capability-mknod.service: Child 8541 belongs to exec-privatedevices-yes-capability-mknod.service.
exec-privatedevices-yes-capability-mknod.service: Main process exited, code=exited, status=1/FAILURE
exec-privatedevices-yes-capability-mknod.service: Failed with result 'exit-code'.
exec-privatedevices-yes-capability-mknod.service: Service will not restart (restart setting)
exec-privatedevices-yes-capability-mknod.service: Changed start -> failed
exec-privatedevices-yes-capability-mknod.service: Unit entered failed state.
test_exec_privatedevices: exec-privatedevices-yes-capability-mknod.service: exit status 1, expected 0
After a little bit of debugging, the issue simmers down to this:
# systemd-run --unit captest.service -p ProtectKernelModules=yes capsh --print && journalctl -b --no-pager -u captest.service --grep cap_sys_module
Running as unit: captest.service
-- Logs begin at Sun 2020-01-12 12:20:52 UTC, end at Sun 2020-01-12 12:42:08 UTC. --
Jan 12 12:42:08 arch.localdomain capsh[5368]: Current: =ep cap_sys_module,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63-ep
i.e. ProtectKernelModules=yes removes CAP_SYS_MODULE from the bounding set, but now, for whatever reason, it is in the current set, which interferes with the grep in each failing test.
I tried to run the reproducer on one of mine (baremetal) Arch machines with a less recent package set and it behaves as 'expected':
# systemctl --version
systemd 244 (244.1-1-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
# uname -r
5.3.8-arch1-1
# systemd-run --unit captest.service -p ProtectKernelModules=yes capsh --print && journalctl -b --no-pager -u captest.service --grep cap_sys_module
Running as unit: captest.service
-- Logs begin at Wed 2018-11-14 13:28:26 CET, end at Sun 2020-01-12 13:48:49 CET. --
-- No entries --
systemd version the issue has been seen with
Used distribution
During today's night the Arch Linux image got updated and with this update several
test-executesubtests started failing, like this one:After a little bit of debugging, the issue simmers down to this:
i.e.
ProtectKernelModules=yesremovesCAP_SYS_MODULEfrom theboundingset, but now, for whatever reason, it is in thecurrentset, which interferes with thegrepin each failing test.I tried to run the reproducer on one of mine (baremetal) Arch machines with a less recent package set and it behaves as 'expected':