Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering 
On Tue, 10.09.13 13:33, Colin Walters (walt...@verbum.org) wrote:

 
 On Tue, 2013-09-10 at 18:47 +0200, Lennart Poettering wrote:
 
  I'd actually prefer having an explicit blacklist for this, so that we
  don't have to trust the initrd too much that...
 
 But nowadays it's systemd running in the initrd, what's not to trust?

Well, might be a different version, might be one without systemd, ...

  However, I'd really like to see this blacklist be unified
  somewhere. Maybe a new function in util.c or so called
  is_os_resource_path()
 
 What would the blacklist contain?  Just / and /usr?  Or would it also
 have /var?

/, /usr, /etc probably.

/var is something where we allow that it is mounted at late boot and
that it is unmounted at late shutdown (at least in theory).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering 
On Tue, 10.09.13 19:54, Tom Gundersen (t...@jklm.no) wrote:

  But it annoys me that we're propagating this hardcoding in the new code
  too.  How about we make systemd inspect /proc/self/mountinfo *very*
  early on at boot when it starts, and ensure skip unmounting these, under
  the assumption they'll be taken care of either in the initrd, or by the
  final kill spree?
 
  I'd actually prefer having an explicit blacklist for this, so that we
  don't have to trust the initrd too much that...
 
 Not sure if I get in what sense you mean we need to trust the initrd.
 What I thought we'd do was to simply notice what filesystems were
 already mounted when systemd first started in the real root (so
 whatever caused them to be mounted in the initrd is not important).

What gives me the headache there is that initrds are so varied right
now. It just gives me headaches leaving it to the numerous initrds
implementations to decide what the file systems with OS resources
are. I'd much rather define clearly that /etc, / and /usr are OS
resources in the systemd context, rather then leave that definition to
the inirds/dsitro packagers... This is too close to the core of the OS
to leave this undefined and varying between the distributions I'd say...

 If you meant we'd need to trust the initrd to umount them correctly at
 shutdown, I guess we could keep doing the umount loop in the real root
 also for the premounted filesystems (and at least remount them ro),
 but not complain too much if we can't umount them, as the failure is
 sort of expected.
 
 I'm not too keen on a blacklist. It would work for the simple case of
 course, but I have seen lots of fancy/complicated stuff being mounted
 in the initrd for people doing live media/install discs, which I
 really don't think we can/should cover by using an explicit list.

Well, everything that this list would declare is that /, /etc, /usr (and
maybe very few others) are the bits that systemd requires to be
mounted when the host's systemd is first invoked. Where it is mounted
from, and in which order would be up to the distros, but I'd really
would like to make it clear that these three dirs *must* be valid when
the host systemd initializes.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Colin Walters 
On Wed, 2013-09-11 at 16:31 +0200, Lennart Poettering wrote:

 Well, everything that this list would declare is that /, /etc, /usr (and
 maybe very few others) are the bits that systemd requires to be
 mounted when the host's systemd is first invoked. Where it is mounted
 from, and in which order would be up to the distros, but I'd really
 would like to make it clear that these three dirs *must* be valid when
 the host systemd initializes.

That makes total sense!  But my concern is more about *unmounting*.  So
let's say that an initramfs uses some special filesystem for /etc that
causes it be a mountpoint; for example, it's backed by a special NVRAM
device.

I think systemd should just assume that the initramfs will take care of
unmounting it, and not attempt to unmount it gracefully by default,
i.e. save it until the final kill spree.  And more generally for all
filesystems that were mounted by the initramfs.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering 
On Wed, 11.09.13 10:46, Colin Walters (walt...@verbum.org) wrote:

 
  Well, everything that this list would declare is that /, /etc, /usr (and
  maybe very few others) are the bits that systemd requires to be
  mounted when the host's systemd is first invoked. Where it is mounted
  from, and in which order would be up to the distros, but I'd really
  would like to make it clear that these three dirs *must* be valid when
  the host systemd initializes.
 
 That makes total sense!  

BTW, I started putting this together:

http://www.freedesktop.org/wiki/Software/systemd/FileHierarchy/

Which is supposed to document the actual requirements systemd
makes. i.e. that subset of the FHS that systemd actually cares
about. Suggestions welcome.

 But my concern is more about *unmounting*.  So
 let's say that an initramfs uses some special filesystem for /etc that
 causes it be a mountpoint; for example, it's backed by a special NVRAM
 device.

Well, but /etc would be one of those which would be listed in that OS
resource dir list... 

 I think systemd should just assume that the initramfs will take care of
 unmounting it, and not attempt to unmount it gracefully by default,
 i.e. save it until the final kill spree.  And more generally for all
 filesystems that were mounted by the initramfs.

Note that killing spree is done before we jump back into the
initramfs...

So there's three steps:

1. normal unmounting using mount units
2. killing spree unmounting of left-overs in a tight loop based on 
/proc/self/mountinfo
3. initrd unmounting of remaining OS resource dirs

Where 3 is optional, and done only on initrds which implement this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Colin Walters 
On Wed, 2013-09-11 at 16:55 +0200, Lennart Poettering wrote:

 Well, but /etc would be one of those which would be listed in that OS
 resource dir list... 

Sure, it makes total sense for systemd to hard require it (and the
others) to be mounted; again I'm just more interested in the unmounting.

 So there's three steps:
 
 1. normal unmounting using mount units

Trying to do this with current ostree is causing problems, and similarly
with special LiveCD setups, and as danpb said a while ago, container
cases where the external system mounts resources for the container.

 2. killing spree unmounting of left-overs in a tight loop based on 
 /proc/self/mountinfo

This part works fine for me.

 3. initrd unmounting of remaining OS resource dirs

And I don't need this myself; having to keep the initramfs around just
to invoke umount() would be kind of lame when systemd can just do it
itself easily enough after all processes other than pid 1 are gone.

So step 3 is only needed AIUI for network/daemon-controlled root
filesystem (per
http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ )



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering 
On Wed, 11.09.13 12:00, Colin Walters (walt...@verbum.org) wrote:

 
 On Wed, 2013-09-11 at 16:55 +0200, Lennart Poettering wrote:
 
  Well, but /etc would be one of those which would be listed in that OS
  resource dir list... 
 
 Sure, it makes total sense for systemd to hard require it (and the
 others) to be mounted; again I'm just more interested in the unmounting.
 
  So there's three steps:
  
  1. normal unmounting using mount units
 
 Trying to do this with current ostree is causing problems, and similarly
 with special LiveCD setups, and as danpb said a while ago, container
 cases where the external system mounts resources for the container.

Can you elaborate on this? Why wouldn't it suffice to drop in a .mount
unit for the mount in question which excludes the mount point from being
unmounted with this?

  2. killing spree unmounting of left-overs in a tight loop based on 
  /proc/self/mountinfo
 
 This part works fine for me.
 
  3. initrd unmounting of remaining OS resource dirs
 
 And I don't need this myself; having to keep the initramfs around just
 to invoke umount() would be kind of lame when systemd can just do it
 itself easily enough after all processes other than pid 1 are gone.
 
 So step 3 is only needed AIUI for network/daemon-controlled root
 filesystem (per
 http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ )

Not just that. Also for complex local storage where some block device
needs to be dissambled before we power down...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Colin Walters 
On Wed, 2013-09-11 at 19:11 +0200, Lennart Poettering wrote:

 Can you elaborate on this? Why wouldn't it suffice to drop in a .mount
 unit for the mount in question which excludes the mount point from being
 unmounted with this?

It doesn't appear possible to remove the default Conflicts= just by
creating /etc/systemd/system/var.mount.

I tried doing my plan of adding a boolean to mount units if we detect
them at coldplug time, and ensuring we pass that from the dracut systemd
to the deserialized main pid.  But what I hit doing that was from
dracut-systemd's perspective it is /sysroot/var, and not /var.  Would
need to do some sort of device/inode pairing to fix up paths after a
potential switch-root.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering 
On Wed, 11.09.13 19:48, Colin Walters (walt...@verbum.org) wrote:

 
 On Wed, 2013-09-11 at 19:11 +0200, Lennart Poettering wrote:
 
  Can you elaborate on this? Why wouldn't it suffice to drop in a .mount
  unit for the mount in question which excludes the mount point from being
  unmounted with this?
 
 It doesn't appear possible to remove the default Conflicts= just by
 creating /etc/systemd/system/var.mount.

You'd have to set DefaultDependencies=no in order to turn the implicit
shutdown.target conflict dep off.

 I tried doing my plan of adding a boolean to mount units if we detect
 them at coldplug time, and ensuring we pass that from the dracut systemd
 to the deserialized main pid.  But what I hit doing that was from
 dracut-systemd's perspective it is /sysroot/var, and not /var.  Would
 need to do some sort of device/inode pairing to fix up paths after a
 potential switch-root.

Still not convinced that we really want to do that. But note that on
Linux mounts have a fixed numeric ID, which is the first column in
/proc/self/mountinfo. You can also query that ID on many (but not all)
file systems via the name_to_handle_at() system call (which is really
nasty to use though, we already use it in path-util.c and tmpfiles.c
already.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-10 Thread Tom Gundersen 
On Tue, Sep 10, 2013 at 6:47 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Fri, 23.08.13 15:51, Colin Walters (walt...@verbum.org) wrote:


 First, thanks for working on this, most of these patches look sane to
 me.

 On Fri, 2013-08-23 at 15:09 +0800, Tom Gundersen wrote:

  +if (path_equal(m-where, /) ||
  +path_equal(m-where, /usr))
  +return false;

 But it annoys me that we're propagating this hardcoding in the new code
 too.  How about we make systemd inspect /proc/self/mountinfo *very*
 early on at boot when it starts, and ensure skip unmounting these, under
 the assumption they'll be taken care of either in the initrd, or by the
 final kill spree?

 I'd actually prefer having an explicit blacklist for this, so that we
 don't have to trust the initrd too much that...

Not sure if I get in what sense you mean we need to trust the initrd.
What I thought we'd do was to simply notice what filesystems were
already mounted when systemd first started in the real root (so
whatever caused them to be mounted in the initrd is not important).

If you meant we'd need to trust the initrd to umount them correctly at
shutdown, I guess we could keep doing the umount loop in the real root
also for the premounted filesystems (and at least remount them ro),
but not complain too much if we can't umount them, as the failure is
sort of expected.

I'm not too keen on a blacklist. It would work for the simple case of
course, but I have seen lots of fancy/complicated stuff being mounted
in the initrd for people doing live media/install discs, which I
really don't think we can/should cover by using an explicit list.

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-10 Thread Colin Guthrie 
'Twas brillig, and Tom Gundersen at 10/09/13 18:54 did gyre and gimble:
 I'm not too keen on a blacklist. It would work for the simple case of
 course, but I have seen lots of fancy/complicated stuff being mounted
 in the initrd for people doing live media/install discs, which I
 really don't think we can/should cover by using an explicit list.

Yeah, I agree with Tom here. This question seems to have come up about
two or three on the list in the last six months or so with different
paths etc.

Something that took note at startup and maintained that state as y ou
described sounds good to me.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-10 Thread Lennart Poettering 
On Fri, 23.08.13 15:51, Colin Walters (walt...@verbum.org) wrote:

 
 First, thanks for working on this, most of these patches look sane to
 me.
 
 On Fri, 2013-08-23 at 15:09 +0800, Tom Gundersen wrote:
 
  +if (path_equal(m-where, /) ||
  +path_equal(m-where, /usr))
  +return false;
 
 But it annoys me that we're propagating this hardcoding in the new code
 too.  How about we make systemd inspect /proc/self/mountinfo *very*
 early on at boot when it starts, and ensure skip unmounting these, under
 the assumption they'll be taken care of either in the initrd, or by the
 final kill spree?

I'd actually prefer having an explicit blacklist for this, so that we
don't have to trust the initrd too much that...

However, I'd really like to see this blacklist be unified
somewhere. Maybe a new function in util.c or so called
is_os_resource_path() or so? It should probably be changed to use
NULSTR_FOREACH or so for the list, so that it is easy to add more
entries when we need that...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-10 Thread Colin Walters 
On Tue, 2013-09-10 at 18:47 +0200, Lennart Poettering wrote:

 I'd actually prefer having an explicit blacklist for this, so that we
 don't have to trust the initrd too much that...

But nowadays it's systemd running in the initrd, what's not to trust?

 However, I'd really like to see this blacklist be unified
 somewhere. Maybe a new function in util.c or so called
 is_os_resource_path()

What would the blacklist contain?  Just / and /usr?  Or would it also
have /var?


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-08-23 Thread Tom Gundersen 
These mounts should be kept around and unmounted in the shutdown ramfs.

Currently, we will still attempt to umount these in the final kill spree, but
we should consider avoiding that too.
---
 src/core/mount.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/core/mount.c b/src/core/mount.c
index 84801e9..369823d 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -447,6 +447,21 @@ static int mount_add_quota_links(Mount *m) {
 return 0;
 }
 
+static bool should_umount(Mount *m) {
+MountParameters *p;
+
+if (path_equal(m-where, /) ||
+path_equal(m-where, /usr))
+return false;
+
+p = get_mount_parameters(m);
+if (p  mount_test_option(p-options, x-initrd.mount) 
+!in_initrd())
+return false;
+
+return true;
+}
+
 static int mount_add_default_dependencies(Mount *m) {
 const char *after, *after2, *online;
 MountParameters *p;
@@ -491,9 +506,11 @@ static int mount_add_default_dependencies(Mount *m) {
 return r;
 }
 
-r = unit_add_two_dependencies_by_name(UNIT(m), UNIT_BEFORE, 
UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, true);
-if (r  0)
-return r;
+if (should_umount(m)) {
+r = unit_add_two_dependencies_by_name(UNIT(m), UNIT_BEFORE, 
UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, true);
+if (r  0)
+return r;
+}
 
 return 0;
 }
@@ -1553,8 +1570,7 @@ static int mount_add_one(
 if (r  0)
 goto fail;
 
-if (!path_equal(where, /) 
-!path_equal(where, /usr)) {
+if (should_umount(MOUNT(u))) {
 r = unit_add_dependency_by_name(u, UNIT_CONFLICTS, 
SPECIAL_UMOUNT_TARGET, NULL, true);
 if (r  0)
 goto fail;
-- 
1.8.3.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel