[systemd-devel] changing the "mount --make-shared /" default

Lennart Poettering lennart at poettering.net
Mon Feb 4 01:30:56 PST 2013

On Fri, 01.02.13 12:50, Jake Edge (jake at lwn.net) wrote:

> [ 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?

Drop a unit file like this one to /etc/systemd/system/make-shared.service:

    Description=I like my hierarchies private
    Before=local-fs-pre.target shutdown.target

    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.


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 Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list