FS#59973 - [systemd] systemd 239 fails to start containers with older versions of systemd

Attached to Project: Arch Linux
Opened by Wouter Van Hemel (wvh) - Friday, 07 September 2018, 22:42 GMT
Last edited by Dave Reisner (falconindy) - Sunday, 09 August 2020, 14:38 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I'm starting CentOS 7.5 machines (with systemd 219) on an Arch Linux host with systemd 239.

None of my (systemd-nspawn) machines can be started since about the update to systemd 239. The problem is with the -U (user namespace) option to systemd-nspawn:

[root@arch ~]# systemctl --version
systemd 239
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid
[root@arch ~]# systemd-nspawn -bUD /home/build/qbuilder/ --network-zone=machines -M qbuilder systemd.legacy_systemd_cgroup_controller=yes
Spawning container builder on /home/build/qbuilder.
Press ^] three times within 1s to kill container.
Selected user namespace base 1649344512 and range 65536.
systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to CentOS Linux 7 (Core)!

Set hostname to <qbuilder>.
Failed to read AF_UNIX datagram queue length, ignoring: No such file or directory
Failed to create root cgroup hierarchy: Permission denied
Failed to allocate manager object: Permission denied
[!!!!!!] Failed to allocate manager object, freezing.


Something changed in the way systemd is handling cgroups recently and I'm not sure how to get systemd-nspawn to work again.

See also:
https://github.com/systemd/systemd/issues/9563

Per that thread, I'd try downgrading to systemd 238, but I don't have that package anymore.
This task depends upon

Closed by  Dave Reisner (falconindy)
Sunday, 09 August 2020, 14:38 GMT
Reason for closing:  Fixed
Additional comments about closing:  No response. Assume fixed as of systemd 244.
Comment by loqs (loqs) - Saturday, 08 September 2018, 12:27 GMT
Does systemd 219 support systemd.legacy_systemd_cgroup_controller=yes ?
I would suggest trying booting the host with systemd.legacy_systemd_cgroup_controller=yes instead and see if that has any effect.
Comment by Wouter Van Hemel (wvh) - Monday, 10 September 2018, 16:34 GMT
Hmm... Either that or the latest kernel upgrade seems to have done the trick. Thanks!

It might be that systemd 219 doesn't support that parameter, but I'm not sure what patches are included in RedHat or CentOS.

Do you happen to know what changed in systemd recently that stopped this from working? Didn't version 238 also use default-hierarchy=hybrid?
Comment by loqs (loqs) - Monday, 10 September 2018, 18:50 GMT
238 used hybrid as well https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/systemd&id=ef53d9ff8f21e3f49ac49c5195581eb921272cc8
You could remove the boot option and see if it was that or the kernel update that resolved the issue.
Comment by Wouter Van Hemel (wvh) - Wednesday, 19 September 2018, 14:07 GMT
  • Field changed: Percent Complete (100% → 0%)
No, there seems to be a bug in systemd 239 where cgroups don't have the right permissions after copy.

https://github.com/systemd/systemd/issues/10026
Comment by Dave Reisner (falconindy) - Sunday, 08 December 2019, 11:22 GMT
This seems to be fixed upstream. Is this still a problem with systemd 244?

Loading...