Re: [systemd-devel] [PATCH 2/4] mount-setup: introduce mount_setup_run_dirs()
On Tue, 07.10.14 14:14, Michal Sekletar (msekl...@redhat.com) wrote: Hence, if a container manager mounts everything properly, then mount_setup() should be a NOP anyway... In theory yes, but in fact not having /run mounted as tmpfs is default in the docker container. I have no strong opinion on whether this is sensible or not, however I think that systemd can be made more resilient and handle such cases. Sorry, but no. /run should be pre-mounted, and if it isn't we need the rights to mount it. We will not boot up a system without /run. That's part of the API for programs, and we will not avoid it. Please ask Docker to premount /run. All distros need /run anyway these days, Debian does, Ubuntu does, Fedora does. Now systemd will try to mount /run on tmpfs, such attempt will fail because of missing capability and then systemd will just hang. Well, just sticking the head in the sand won't help. If we don't have /run mounted, then things will break later on. We cannot ignore that. Sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] mount-setup: introduce mount_setup_run_dirs()
On 10/08/2014 07:40 AM, Lennart Poettering wrote: On Tue, 07.10.14 14:14, Michal Sekletar (msekl...@redhat.com) wrote: Hence, if a container manager mounts everything properly, then mount_setup() should be a NOP anyway... In theory yes, but in fact not having /run mounted as tmpfs is default in the docker container. I have no strong opinion on whether this is sensible or not, however I think that systemd can be made more resilient and handle such cases. Sorry, but no. /run should be pre-mounted, and if it isn't we need the rights to mount it. We will not boot up a system without /run. That's part of the API for programs, and we will not avoid it. Please ask Docker to premount /run. All distros need /run anyway these days, Debian does, Ubuntu does, Fedora does. Now systemd will try to mount /run on tmpfs, such attempt will fail because of missing capability and then systemd will just hang. Well, just sticking the head in the sand won't help. If we don't have /run mounted, then things will break later on. We cannot ignore that. Sorry, Lennart We have a patch for this. In the past docker has bocked/removed the patch because there is no concept of systemd-tmpfs inside a container to pre-populate /run. So images came with content in their /run. Alex wrote a patch to scan the /run on the image and create the content in a tmpfs /run. I will attempt to push this patch again to docker. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] mount-setup: introduce mount_setup_run_dirs()
On Thu, Oct 02, 2014 at 11:43:22AM +0200, Lennart Poettering wrote: On Thu, 02.10.14 09:57, Michal Sekletar (msekl...@redhat.com) wrote: In cases when we are running as system manager, but we don't have the capability to mount filesystems don't call mount_setup(). However we assume that some directories (e.g. /run/systemd) are always around. Hence don't create those directories in mount_setup(). --- src/core/main.c| 7 ++- src/core/mount-setup.c | 20 src/core/mount-setup.h | 1 + 3 files changed, 19 insertions(+), 9 deletions(-) diff --git a/src/core/main.c b/src/core/main.c index 1a62e04..fcd9471 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -1393,10 +1393,15 @@ int main(int argc, char *argv[]) { /* Mount /proc, /sys and friends, so that /proc/cmdline and * /proc/$PID/fd is available. */ -if (getpid() == 1) { +if (getpid() == 1 have_effective_cap(CAP_SYS_ADMIN)) { r = mount_setup(loaded_policy); if (r 0) goto finish; Hmm, is this really necessary? I mean, the code in mount_setup() will anyway only mount what is missing, but not overmount what is already mounted. I think it is necessary to make possible to run systemd in a docker container. Hence, if a container manager mounts everything properly, then mount_setup() should be a NOP anyway... In theory yes, but in fact not having /run mounted as tmpfs is default in the docker container. I have no strong opinion on whether this is sensible or not, however I think that systemd can be made more resilient and handle such cases. Now systemd will try to mount /run on tmpfs, such attempt will fail because of missing capability and then systemd will just hang. Michal Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] mount-setup: introduce mount_setup_run_dirs()
On Thu, 02.10.14 09:57, Michal Sekletar (msekl...@redhat.com) wrote: In cases when we are running as system manager, but we don't have the capability to mount filesystems don't call mount_setup(). However we assume that some directories (e.g. /run/systemd) are always around. Hence don't create those directories in mount_setup(). --- src/core/main.c| 7 ++- src/core/mount-setup.c | 20 src/core/mount-setup.h | 1 + 3 files changed, 19 insertions(+), 9 deletions(-) diff --git a/src/core/main.c b/src/core/main.c index 1a62e04..fcd9471 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -1393,10 +1393,15 @@ int main(int argc, char *argv[]) { /* Mount /proc, /sys and friends, so that /proc/cmdline and * /proc/$PID/fd is available. */ -if (getpid() == 1) { +if (getpid() == 1 have_effective_cap(CAP_SYS_ADMIN)) { r = mount_setup(loaded_policy); if (r 0) goto finish; Hmm, is this really necessary? I mean, the code in mount_setup() will anyway only mount what is missing, but not overmount what is already mounted. Hence, if a container manager mounts everything properly, then mount_setup() should be a NOP anyway... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel