[systemd-devel] learning how to run systemd in a container, journal shows errors I would like to understand what they mean and why

[Daniel Walsh]

On 3/25/22 17:11, Michal Koutný wrote:
> Hello Masber.
>
> On Fri, Mar 25, 2022 at 11:52:33AM +0000, masber masber <masber at hotmail.com> wrote:
>> I have a k8s cluster with docker as container runtime and am I trying
>> to make systemd to work.
>> I read this doc https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container#enter_oci_hooks and I have systemd running in a container.
> Note the article is almost six years old. Plenty things were implemented
> and configs changed since then.
>
>> Mar 25 11:24:31 nid001002-cluster-1 systemd[1]: Failed to reset devices.list on /kubepods/burstable/podcd69d169-d610-4af7-895a-eb86ee74ed49/4caa4403b8b6d263012e95ca51357ab0bb46fb3bc7a23221115d22efb757cc9c/system.slice/etc-resolv.conf.mount: Operation not permitted
>>
>> I would like to ask the meaning of this message and how to solve it (if possible)
> This message says that the containerized systemd attempts to set some
> cgroup attributes (in this case regarding device access rules via
> devices controller, DeviceAllow= directive) but it fails.
> Effectively it could mean your container failed to made itself more
> secure but it should not affect functionality (from what you provided
> here).
>
> You say you run this in an unprivileged container, a responsible runtime
> would not set up access to v1 controllers (devices is v1 only), so EPERM
> is sort of expected. For the unprivileged containers, I'd suggest you
> switch the host into unified cgroup mode (and consequently the container
> too). That should resolve the reported problem but there may still
> something else that breaks your containerized systemd.
>
> HTH,
> Michal
>
I would also advise you to switch to Podman which makes running 
containized systemd easy and is fully supported.