[systemd-devel] network and remote-fs on shutdown

Lennart Poettering lennart at poettering.net
Mon Sep 10 14:11:45 PDT 2012

On Wed, 05.09.12 20:52, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> > [Mount]
> > What=//
> > Where=/mnt/be
> > Type=cifs
> > FsckPassNo=0
> > Options=/home/mlo/.samba/credentials,noauto,user,x-systemd.automount,x-systemd.device-timeout=60
> > 
> > 
> > If I understand it correctly, there is no dependency between the mount
> > and the network target and this is why my network manager daemon stops
> > before the remote filesystems are unmounted.
> That indeed seems like a correct analysis, but there are further things
> to consider here too.
> The generated unit does have a After=remote-fs-pre.target, which in turn
> has an After=network.target dep. Therefore, your mount unit itself
> inherits this.

Yes, this should work as long as the networking daemon ins ordered
before network.target.

> I thought it was possible to use use "systemctl show yourmount.mount" to
> see the full set of After= units after taking this chain of deps into
> account, but it's not the case here. Not sure if this has always been
> this way, of if I'm just misremembering.

"systemctl show" will show you the properties of the unit itself, it
will not recursively traverse the dep chain however. You currently have
to do that manually. We should add a tool one day though that can
break down this dep graph into a tree and show that on the console.

> Anyway, systemd should reverse the After logic for shutdown, but I guess
> it's maybe not dealing with this chain and thus not doing the order
> order properly. If so this might be a bug, or it might be intended
> behaviour.

That is correct. It would be good to checkout if the networking daemon
is properly ordered against network.target however. Normally the
ordering should be:

networking deaemon
the various remote fs

This is the boot-up order, and the shutdown order should implicitly be
the reverse of this, so this should work.


Lennart Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list