Discussion:
[systemd-devel] changing the "mount --make-shared /" default
Jake Edge
2013-02-01 19:50:01 UTC
Permalink
[ OK, let's try this again ... since I'm impatient about it sitting in
the moderator queue, I went ahead and joined up ]

Hi Lennart (and the rest of the systemd gang),

I was quite surprised by some behavior that I found today in Fedora 18,
which I think comes from systemd. I was trying to play with mount
namespaces and was rather surprised to find that they didn't work as
expected. After some googling, I realized that Fedora makes / a shared
mount by default. That appears to come from:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0

where you say:

Setups which prefer the default of "private" should undo this change
via invoking "mount --make-private /" or a similar command after boot.

I am not sure that I want the default to be "private", but if I did,
what is the proper, systemd-ish way to do so?

thanks,

jake
--
Jake Edge - LWN - ***@lwn.net - http://lwn.net
Colin Walters
2013-02-01 21:33:26 UTC
Permalink
Post by Jake Edge
I am not sure that I want the default to be "private", but if I did,
what is the proper, systemd-ish way to do so?
If you're creating a private mount namespace, then:

http://git.gnome.org/browse/linux-user-chroot/tree/src/linux-user-chroot.c#n300
Jake Edge
2013-02-01 21:40:29 UTC
Permalink
Post by Colin Walters
Post by Jake Edge
I am not sure that I want the default to be "private", but if I did,
what is the proper, systemd-ish way to do so?
http://git.gnome.org/browse/linux-user-chroot/tree/src/linux-user-chroot.c#n300
Yes, that's a way to programmatically do it on an as-needed basis, which
is great, thanks. But what I was looking for was a way to tell systemd
to change the default back to private at boot time as Lennart
suggested in the commit. Obviously the code in systemd could be changed
locally, but that seems a tad ... inelegant ...

jake
--
Jake Edge - LWN - ***@lwn.net - http://lwn.net
Colin Walters
2013-02-01 21:59:19 UTC
Permalink
Post by Jake Edge
Post by Colin Walters
Post by Jake Edge
I am not sure that I want the default to be "private", but if I did,
what is the proper, systemd-ish way to do so?
http://git.gnome.org/browse/linux-user-chroot/tree/src/linux-user-chroot.c#n300
Yes, that's a way to programmatically do it on an as-needed basis, which
is great, thanks. But what I was looking for was a way to tell systemd
to change the default back to private at boot time as Lennart
suggested in the commit.
That has global system ramifications. It's somewhat unfortunate that
systemd overrides the kernel, but going forward programs can (at the
moment) assume under systemd that it's shared, and make things private
as necessary. If there were a configuration toggle, programs would have
to cope with both cases. Though maybe realistically they already have
to if Upstart doesn't do the same thing.

Anyways, a unit which just invokes mount --make-rprivate / after say
basic.target would probably work.

There's some decent docs here btw, which do predate systemd and thus
claim the default is private:
http://www.ibm.com/developerworks/linux/library/l-mount-namespaces/index.html
Jake Edge
2013-02-01 22:10:22 UTC
Permalink
Post by Colin Walters
Post by Jake Edge
Yes, that's a way to programmatically do it on an as-needed basis,
which is great, thanks. But what I was looking for was a way to
tell systemd to change the default back to private at boot time as
Lennart suggested in the commit.
That has global system ramifications.
Sure. Of course, the original change to shared did too :)
Post by Colin Walters
It's somewhat unfortunate that
systemd overrides the kernel, but going forward programs can (at the
moment) assume under systemd that it's shared, and make things private
as necessary. If there were a configuration toggle, programs would
have to cope with both cases. Though maybe realistically they
already have to if Upstart doesn't do the same thing.
It seems a little unfortunate that programs have to "know" what init
system they are running under. Even if Upstart does change the kernel
default (I have no idea one way or the other), sysvinit or some other
init probably doesn't. Any program that wants to work correctly
"everywhere" needs to set the expected behavior, I guess, even those
that are currently expecting to find shared mounts. And that probably
was true with or without the change Lennart made ...

jake
--
Jake Edge - LWN - ***@lwn.net - http://lwn.net
Lennart Poettering
2013-02-04 09:35:04 UTC
Permalink
Post by Jake Edge
It seems a little unfortunate that programs have to "know" what init
system they are running under. Even if Upstart does change the kernel
default (I have no idea one way or the other), sysvinit or some other
init probably doesn't. Any program that wants to work correctly
"everywhere" needs to set the expected behavior, I guess, even those
that are currently expecting to find shared mounts. And that probably
was true with or without the change Lennart made ...
Well, most container/namespace solutions used to plug "mount
--make-rshared /" or something similar into the boot somewhere, since
shared behaviour is what they usually want. With systemd we now made
that unnecessary, and cleaned things up a bit, since doing such a global
change in individual packages is nor particularly nice and not easy to
get race-free.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Mantas Mikulėnas
2013-02-01 22:31:36 UTC
Permalink
Post by Colin Walters
Anyways, a unit which just invokes mount --make-rprivate / after say
basic.target would probably work.
I think the next version of util-linux will support "rprivate" as a
fstab option (commit 6498ece0e77).

--
Mantas Mikulėnas
Lennart Poettering
2013-02-04 09:30:56 UTC
Permalink
Post by Jake Edge
[ OK, let's try this again ... since I'm impatient about it sitting in
the moderator queue, I went ahead and joined up ]
Hi Lennart (and the rest of the systemd gang),
I was quite surprised by some behavior that I found today in Fedora 18,
which I think comes from systemd. I was trying to play with mount
namespaces and was rather surprised to find that they didn't work as
expected. After some googling, I realized that Fedora makes / a shared
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0
Setups which prefer the default of "private" should undo this change
via invoking "mount --make-private /" or a similar command after boot.
I am not sure that I want the default to be "private", but if I did,
what is the proper, systemd-ish way to do so?
Drop a unit file like this one to /etc/systemd/system/make-shared.service:

[Unit]
Description=I like my hierarchies private
DefaultDependencies=no
Conflicts=shutdown.target
Before=local-fs-pre.target shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/mount --make-rprivate /

And then pull this into the early boot:

# mkdir -p /etc/systemd/system/local-fs.target.wants/
# ln -s ../make-shared.service /etc/systemd/system/local-fs.target.wants/

I didn't test this, but it should do the job, nicely.

Explanations:

As this is an early boot process we need to disable the default
ordering/requirement dependencies systemd adds to services via
DefaultDependencies=no. Then, we order ourselves before
"local-fs-pre.target", which has the benefit that we can be sure that
further mounted fs will inherit the flag nicely and
race-freely. local-fs-pre.target is ordered after all local mounts.

We also order ourselves relative to shutdown.target, which ensures this
unit is stopped at shutdown. This is just to make things nice, and
actually has very little effect, as the unit doesn't do anything anyway
when stopped.

We use Type=oneshot since the specified command should be executed at
boot and be waited for before boot progresses (adhering to the ordering
dependencies expressed in [Unit]).

We use RemainAfterExit=yes so that the unit stays around after it is
started, so that we can easily check after boot if it got properly
started during boot.

Finally, the ln -s line makes sure the unit is activated as part of
local-fs.target, which is where all local file system units tend to be
pulled in.

Hope this makes sense!

Lennart
--
Lennart Poettering - Red Hat, Inc.
Lennart Poettering
2013-02-04 09:40:30 UTC
Permalink
On Mon, 04.02.13 10:30, Lennart Poettering (***@poettering.net) wrote:

Oh, meh, I shouldn't write emails this early in the day.
Post by Lennart Poettering
As this is an early boot process we need to disable the default
^ "unit" is missing here
Post by Lennart Poettering
ordering/requirement dependencies systemd adds to services via
DefaultDependencies=no. Then, we order ourselves before
"local-fs-pre.target", which has the benefit that we can be sure that
further mounted fs will inherit the flag nicely and
race-freely. local-fs-pre.target is ordered after all local mounts.
^^^^^ that's supposed to read "before"

Lennart
--
Lennart Poettering - Red Hat, Inc.
Tom Gundersen
2013-02-04 12:36:31 UTC
Permalink
Post by Lennart Poettering
Post by Jake Edge
[ OK, let's try this again ... since I'm impatient about it sitting in
the moderator queue, I went ahead and joined up ]
Hi Lennart (and the rest of the systemd gang),
I was quite surprised by some behavior that I found today in Fedora 18,
which I think comes from systemd. I was trying to play with mount
namespaces and was rather surprised to find that they didn't work as
expected. After some googling, I realized that Fedora makes / a shared
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0
Post by Lennart Poettering
Post by Jake Edge
Setups which prefer the default of "private" should undo this change
via invoking "mount --make-private /" or a similar command after boot.
I am not sure that I want the default to be "private", but if I did,
what is the proper, systemd-ish way to do so?
[Unit]
Description=I like my hierarchies private
DefaultDependencies=no
Conflicts=shutdown.target
Before=local-fs-pre.target shutdown.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/mount --make-rprivate /
# mkdir -p /etc/systemd/system/local-fs.target.wants/
# ln -s ../make-shared.service
/etc/systemd/system/local-fs.target.wants/
Post by Lennart Poettering
I didn't test this, but it should do the job, nicely.
As this is an early boot process we need to disable the default
ordering/requirement dependencies systemd adds to services via
DefaultDependencies=no. Then, we order ourselves before
"local-fs-pre.target", which has the benefit that we can be sure that
further mounted fs will inherit the flag nicely and
race-freely. local-fs-pre.target is ordered after all local mounts.
*before*?
Post by Lennart Poettering
We also order ourselves relative to shutdown.target, which ensures this
unit is stopped at shutdown. This is just to make things nice, and
actually has very little effect, as the unit doesn't do anything anyway
when stopped.
We use Type=oneshot since the specified command should be executed at
boot and be waited for before boot progresses (adhering to the ordering
dependencies expressed in [Unit]).
We use RemainAfterExit=yes so that the unit stays around after it is
started, so that we can easily check after boot if it got properly
started during boot.
Finally, the ln -s line makes sure the unit is activated as part of
local-fs.target, which is where all local file system units tend to be
pulled in.
Hope this makes sense!
Lennart
--
Lennart Poettering - Red Hat, Inc.
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Tom Gundersen
2013-02-04 12:37:39 UTC
Permalink
Post by Tom Gundersen
Post by Lennart Poettering
Post by Jake Edge
[ OK, let's try this again ... since I'm impatient about it sitting in
the moderator queue, I went ahead and joined up ]
Hi Lennart (and the rest of the systemd gang),
I was quite surprised by some behavior that I found today in Fedora 18,
which I think comes from systemd. I was trying to play with mount
namespaces and was rather surprised to find that they didn't work as
expected. After some googling, I realized that Fedora makes / a shared
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0
Post by Tom Gundersen
Post by Lennart Poettering
Post by Jake Edge
Setups which prefer the default of "private" should undo this change
via invoking "mount --make-private /" or a similar command after boot.
I am not sure that I want the default to be "private", but if I did,
what is the proper, systemd-ish way to do so?
Drop a unit file like this one to
[Unit]
Description=I like my hierarchies private
DefaultDependencies=no
Conflicts=shutdown.target
Before=local-fs-pre.target shutdown.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/mount --make-rprivate /
# mkdir -p /etc/systemd/system/local-fs.target.wants/
# ln -s ../make-shared.service
/etc/systemd/system/local-fs.target.wants/
Post by Tom Gundersen
Post by Lennart Poettering
I didn't test this, but it should do the job, nicely.
As this is an early boot process we need to disable the default
ordering/requirement dependencies systemd adds to services via
DefaultDependencies=no. Then, we order ourselves before
"local-fs-pre.target", which has the benefit that we can be sure that
further mounted fs will inherit the flag nicely and
race-freely. local-fs-pre.target is ordered after all local mounts.
*before*?
Meh, scratch that, Lennart already corrected it.
Post by Tom Gundersen
Post by Lennart Poettering
We also order ourselves relative to shutdown.target, which ensures this
unit is stopped at shutdown. This is just to make things nice, and
actually has very little effect, as the unit doesn't do anything anyway
when stopped.
We use Type=oneshot since the specified command should be executed at
boot and be waited for before boot progresses (adhering to the ordering
dependencies expressed in [Unit]).
We use RemainAfterExit=yes so that the unit stays around after it is
started, so that we can easily check after boot if it got properly
started during boot.
Finally, the ln -s line makes sure the unit is activated as part of
local-fs.target, which is where all local file system units tend to be
pulled in.
Hope this makes sense!
Lennart
--
Lennart Poettering - Red Hat, Inc.
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Continue reading on narkive:
Loading...