Why do I get this message in my container's syslog : Failed to kill control group


(John R) #1

What does this error message mean from inside a container?
It’s very prevalent which I can see from journalctl -b

systemd[1]: systemd-sysctl.service: Failed to kill control group /lxc//system.slice/systemd-sysctl.service, , ignoring: Invalid argument

plymouth-read-write.service: Failed to kill control group /lxc//system.slice/plymouth-read-write.service, ignoring: Invalid argument

LXD v2.20


(Stéphane Graber) #2

@brauner any idea of what's systemd trying to do here? :slight_smile:


(Christian Brauner) #3

I suspect that systemd realizes that it can't start the relevant service as it is in a user namspace and simply moves on as it should but also tries to cleanup the corresponding cgroup it created for the service but fails to do so. Seems like it doesn't see this as an error as well and simply moves on. I wouldn't worry about it.


(Stéphane Graber) #4

Yeah, but this one looks new, I'm used to systemd failing to mess with the devices cgroup but this is a new one, not sure exactly what it's trying to do with killing a cgroup here and whether that means it actually failed to kill some processes.


(Christian Brauner) #5

What systemd version is that?


(John R) #6

The hosting company I'm using is Scaleway, and they have just brought out a new kernel.
Linux zentyal1 4.14.4-mainline-rev1 #1 SMP Tue Dec 5 13:08:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Not realised the significance until reading one of @simos posts, that Scaleway use Mainline kernels and not Ubuntu ones.

So I've now tried 4.14, and the error message changes to that I show below.

Whether this same cause, I don't know but the error message looks more sensible now, and I've tested using a script, that there is no failure - just a warning message. So perhaps @brauner is right and it can be ignored.

I'm using Ubuntu 16.04, so Systemd sticks at 229

systemd --version

systemd 229
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN

Dec 07 19:39:29 zentyal1 systemd[1]: Reached target Local File Systems (Pre).
Dec 07 19:39:29 zentyal1 systemd[1]: Reached target Local File Systems.
Dec 07 19:39:29 zentyal1 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-read-write.service: Opera
Dec 07 19:39:29 zentyal1 systemd[1]: Starting Tell Plymouth To Write Out Runtime Data...
Dec 07 19:39:29 zentyal1 systemd[1]: Failed to reset devices.list on /system.slice/apparmor.service: Operation not pe
Dec 07 19:39:29 zentyal1 systemd[1]: Starting LSB: AppArmor initialization...
Dec 07 19:39:29 zentyal1 systemd[1]: Failed to reset devices.list on /system.slice/system-getty.slice: Operation not
Dec 07 19:39:29 zentyal1 systemd[1]: Created slice system-getty.slice.


(Stéphane Graber) #7

Ok, your logs look more normal now. It's still annoying that systemd complains about failures to modify devices.list within a userns, but it's not harmful, just annoying :slight_smile:

@brauner what are the chances we can get systemd upstream to ignore EPERM when writing to devices.list inside a userns? it's just cosmetic but given the number of users that keep reporting this as an issue, it'd save us some time :slight_smile:


(Christian Brauner) #8

This shouldn't be an issue with systemd 235 onwards. This is just an issue for older systemd releases. :slight_smile: