Bug 1283891

Yet another symptom of known incompatibles between docker and systemd. Systemd requires /run to be on tmpfs. 

Internal rm_rf function by default refuses to remove any file if it is not on tmpfs (because if you/we sc... something up, than you can fixit by reboot).

And on reload we delete the generators dirs and run generators again.

We require /run on tmpfs.

(In reply to Lukáš Nykrýn from comment #3)
> We require /run on tmpfs.

Or we need the assumption on systemd side relaxed, potentially based on the container environment variable.

I believe we need to fix the docker environment to provide systemd the environment it expects.  We have most of this done, but are hung up on handling of the cgroup file system inside of the container.

In docker-1.10  you will be able to do something like


docker run -d --stop-signal=RTMIN+3  --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup:ro systemdcontainer

This will get you most of the way there, the container will be able to run without privileged I believe.  The problem with this is the cgroup config is writable so systemd will attempt to write to it, and be blocked by SELinux.  In a perfect world, we could mount the cgroups read/only or in the future their will be namespaced cgroups so the systemd inside of the container will only get a subsection of the cgroup controls.

We are attempting to build a docker hook that will setup the tmpfs and cgroups outside of user control.

(In reply to Daniel Walsh from comment #5)
> I believe we need to fix the docker environment to provide systemd the
> environment it expects.  We have most of this done, but are hung up on
> handling of the cgroup file system inside of the container.
> 
> In docker-1.10  you will be able to do something like
> 
> docker run -d --stop-signal=RTMIN+3  --tmpfs /run --tmpfs /tmp -v
> /sys/fs/cgroup:/sys/fs/cgroup:ro systemdcontainer

I wonder, how should things be configured for atomic (command) in compatible ways? When we start putting --tmpfs to LABELs, the docker run's will start failing when run on older dockers.

Created attachment 1115849 [details]
Doing some hacking on a flight to LA.

Using this script will get you a little further, you could add the --tmpfs /run switch and I think systemd will come up a little more securely.  Sadly this will not get you fully where you want.

Adding oci-systemd and oci-register-machine hooks with our docker-1.10 get me to the state where systemd runs in a non --privileged container and

journalctl -M CONTINAERID

Works outside of the container.  Some how getting this to happen all under the covers would be my nirvana.

I don't we should add these to tools until docker-1.10.  We might want to add something to the LABEL spec to state prereqs for containers, As we slowly build a new version of rpm.

oci-register-machine got into rawhide today.  Next step is oci-systemd-hook.

Fixed in docker-1.10.

With docker-1.10.3-31.el7.x86_64 and oci-register-machine-1.10.3-31.el7.x86_64 and oci-systemd-hook-1.10.3-31.el7.x86_64 installed, I still see the

Failed to create unit file /run/systemd/generator.late/netconsole.service: File exists
Failed to create unit file /run/systemd/generator.late/network.service: File exists

errors when running commands from commment 0.

Any idea why?  What does the dockerfile look like.  Does this work in permissive mode?

The problem is present with Dockerfile

FROM rhel7.2
RUN yum install -y --disablerepo='*-rpms' --enablerepo=rhel-7-server-rpms initscripts && yum clean all
VOLUME [ "/tmp", "/run" ]
CMD [ "/usr/sbin/init" ]
LABEL RUN "docker run -ti -v /sys/fs/cgroup:/sys/fs/cgroup:ro ${NAME}"

and is caused by the fact that the VOLUME definition in the Dockerfile prevents the oci-systemd-hook to mount /tmp and /run as tmpfs -- they are xfs.

When I comment out the

VOLUME [ "/tmp", "/run" ]

line, the problem disappears.

So this looks like it becomes an instance of bug 1331781.

Yup, but I would just suggest that we remove those.

Also with oci-systemd-hook you should not need  -v /sys/fs/cgroup:/sys/fs/cgroup:ro

In docker-1.10.3-40.el7.x86_64 , works well

# cat Dockerfile 
FROM fedora
RUN yum install -y  initscripts && yum clean all
CMD [ "/usr/sbin/init" ]
LABEL RUN "docker run -ti ${NAME}"

# docker build . 
# docker run -it --name systemd -v /sys/fs/cgroup:/sys/fs/cgroup:ro 5aefc25d4331

# docker exec systemd systemctl daemon-reload

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1274