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
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.
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.
What systemd version is that?
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 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.
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 
@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
This shouldn’t be an issue with systemd 235 onwards. This is just an issue for older systemd releases.