Bug 1282945 - /run should not be a volume
/run should not be a volume
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rhel-server-docker (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Frantisek Kluknavsky
Depends On:
Blocks: 1282733
  Show dependency treegraph
Reported: 2015-11-17 16:10 EST by Scott Dodson
Modified: 2015-12-08 09:04 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-08 09:04:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Scott Dodson 2015-11-17 16:10:11 EST
After much investigation we arrived at the fact that the rhel7.2 base image has added a volume for /run/ this breaks building images that depend on persisting anything in /run/ if you're not a root user lacking permissions to create data in /run/ during startup.

See https://bugzilla.redhat.com/show_bug.cgi?id=1282733

We can come up with no solution to this problem.
Comment 4 Daniel Walsh 2015-11-23 11:30:04 EST
Yes we should not have /run as a volume in the base image.  We are working on other solutions for handling systemd in the container.  --tmpfs patch is moving  along and dockerhooks are both better solutions.
Comment 5 Stephen Tweedie 2015-11-23 12:16:36 EST
(In reply to Daniel Walsh from comment #4)
> Yes we should not have /run as a volume in the base image.

Trouble is, *not* having it breaks things.  As one specific example, on rhel7/rhel-7.1-24, we don't have /run and so we get a broken fs symlink for an important sub-directory:

# docker run --rm -ti rhel7/rhel:7.1-24 ls -l /var/lock
lrwxrwxrwx. 1 root root 11 Oct 30 07:05 /var/lock -> ../run/lock

See https://bugzilla.redhat.com/show_bug.cgi?id=1105616
    "Base image is missing several files from /run/*"

> We are working
> on other solutions for handling systemd in the container.  --tmpfs patch is
> moving  along and dockerhooks are both better solutions.
Comment 6 Daniel Walsh 2015-11-23 12:50:58 EST
In that case the image should just create /run/lock.  Not use volume mounts.
Comment 7 Daniel Walsh 2015-11-23 12:54:25 EST
Docker has specified that /run on the image should be populated by the tools installed, for example "yum install httpd" will create /run/httpd on the image.

The secrets patch should not create a volume, but will create a mount point /run/secrets I believe.  But docker build will not save the content in this directory to an image.
Comment 8 Stephen Tweedie 2015-11-23 13:04:38 EST
OK -- then yes, this definitely shouldn't be a volume in the base image.  

Do we know why the /run volume was added?  Any expected consequences of reverting that change?
Comment 9 Frantisek Kluknavsky 2015-11-23 13:26:06 EST
Primary expected consequence would be systemd not running.
Comment 10 Frantisek Kluknavsky 2015-11-23 13:33:26 EST
(Of course the user can fix it easily when running the container. I meant, systemd not running out of box.)
Comment 11 Stephen Tweedie 2015-11-23 13:47:09 EST
OK; for now I think it's far preferable to require the user does a manual
  VOLUME /run
for the special case of running systemd, than to be unable to persist anything in /run.

It would be nice if we could handle this automatically in the future, but for now should we not just revert the VOLUME in the base image?
Comment 17 Martin Jenner 2015-12-07 11:56:54 EST
# docker inspect registry.access.stage.redhat.com/rhel7.2:7.2-38

        "Image": "",
        "Volumes": null,
Comment 19 errata-xmlrpc 2015-12-08 09:04:05 EST
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.


Note You need to log in before you can comment on or make changes to this bug.