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