| Summary: | entrypoint script name 'init' causes debian images to mount /run as tmpfs | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ulf Seltmann <ulf.seltmann> |
| Component: | oci-systemd-hook | Assignee: | Mrunal Patel <mpatel> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | adimania, admiller, amurdaca, dwalsh, ichavero, jcajka, jchaloup, lsm5, marianne, miminar, nalin, ppyy, riek, ulf.seltmann, vbatts |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-10-18 15:08:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Ulf Seltmann
2016-09-13 15:44:51 UTC
Dan (Walsh) - this could be caused by oci-systemd-hook which is probably thinking that /init is systemd and ends up mounting /run as a tmpfs. To the op: if you remove oci-systemd-hook with "rm -rf /usr/libexec/oci/hooks.d/oci-systemd-hook" does the problem persist? Confirmed, this is a bug with oci-systemd-hook - by uninstalling oci-systemd-hook or rm'ing the oci-systemd-hook binary under /usr/libexec/oci/hooks.d/, /run isn't mounted as a tmpfs. Dan, what would you do here? I'm not really saying this is a bug though - it's probably the expected behavior with "oci-systemd-hook" and probably needs more documentation around the entrypoint name - just thinking out loud. oci-systemd-hook looks for init or systemd as the entrypoint and makes the assumption that you are running systemd inside the container. Is there something that is breaking or is this just you would prefer /run to not be on a tmpfs? (In reply to Daniel Walsh from comment #4) > oci-systemd-hook looks for init or systemd as the entrypoint and makes the > assumption that you are running systemd inside the container. Is there > something that is breaking or is this just you would prefer /run to not be > on a tmpfs? first of all its inconsistent among different host oses since at least ubuntu is not mounting /run as tmpfs second it breaks volume mapping e.g. /var/run/mysqld for sharing mysqld's socket because the systemd-mount is overlaying and in debian /var/run is a symlink to /run. not to mention that installing apps like apache2 create directories under /var/run. needless to say that this directories are missing as well if systemd mounts /run as tmpfs on container startup. But it is consistent with the host you are running it on. The code should handle the fact that a /run is on any kind of file system. THe breaks the volume mapping is not supposed to happen. There is a patch that is supposed to copy the underlying file system ontop of the tmpfs in runc. That should be implemented in oci-register-machine. ANything that is in /run on the host image should show up on the tmpfs in the image. If you were running systemd as pid 1 it would have populated the /run tmpfs using systemd-tmpfiles just like it does in Fedora/Centos/RHEL. The problem here is that you were using a non systemd init program and confused the tool. Bottom line we should fix the mounting of the tmpfs to have the underlying content. (In reply to Daniel Walsh from comment #6) > But it is consistent with the host you are running it on. The code should > handle the fact that a /run is on any kind of file system. how is it consistency when a debian image behaves differently depending on the underlying host system? isnt docker supposed to abstract host differences and handle all images the same regardless where they are running? > > THe breaks the volume mapping is not supposed to happen. There is a patch > that is supposed to copy the underlying file system ontop of the tmpfs in > runc. by "copy the underlying filesystem ontop" you mean literally copying the files and folder structure over into the /run folder? because this is not a satisfying solution (which is not working whatsoever). the big advantage of bind mounts is that you can modify the content bidirectional. copying the content creates - obviously - a copy and all changes are made to the copy. bind mounts should continue to work. If you volume mount in -v /run/foobar, then this should get mounted on the tmpfs /run/foobar. There are always going to be differences between distributions, and versions of docker. There is no guarantee that containers will work on every platform, although that is the goal. I personally believe that most containers should run in --read-only mode with tmpfs mounted on /run and /tmp, to prevent a hacked version of an application from modifying the container image. The goal is the debian image not to run differently, if it does then this is a bug. If there was a directory in /run/mariadb or /run/httpd in the image and this does not show up on the /run tmpfs then this is a bug. OK. so if you need anything else from me than the description i provided in this issue, let me know. |