Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#11437 - [initscripts] Add in scripts rc.sysinit/rc.shutdown/netfs test "-O _netdev" for mount/umount

Attached to Project: Arch Linux
Opened by Marco (cipparello) - Wednesday, 10 September 2008, 20:21 GMT
Last edited by Thomas Bächler (brain0) - Monday, 09 November 2009, 13:56 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


as reported in mount(8)/umount(8) the option "_netdev" specifies that the device resides over the network and therefore the
network connection is required to access it. Since in these days I'm building an iSCSI SAN solution I noticed, after tests to
simulate various scenarios, that Archlinux isn't '_netdev aware' in particular:

now the script tries to umount any fs still mounted but ignores the _netdev option so, if any network device is still mounted, the
process remains in freeze (since there isn't any network connection) and the only solution to continue is to hard reset the server.

now the script, after the checking filesystems, tries to mount any local fs (thanks to $NETFS) but again if there's in fstab an
entry with '_netdev' option it is recognized as 'local fs' and the command try to mount it (I know about the option 'noauto'...).

now the script tries to mount/umount only remote fs but isn't aware of the fstab entries with option _netdev.

I think about it more as a feature than as a bug since maybe not so many archers have these kind of problems with network device.

Thanks for any response or better solutions.

Possible patches to add these feature are attached.

This task depends upon

Closed by  Thomas Bächler (brain0)
Monday, 09 November 2009, 13:56 GMT
Reason for closing:  Implemented
Comment by Bill (QuimaxW) - Sunday, 11 January 2009, 14:07 GMT
I've been wondering myself why it turns off the network before unmounting the nfs mount when it's shuting down.

My myth front end auto mounts an NFS share from the back end server. On shutdown, it kills the network before trying to unmount the nfs share, it hangs for 30-120 seconds or so, then powers down anyways.

It would make sense to unmount the NETFS$ mounts, then kill the network before unmounting the local file systems.
Comment by Gavin Bisesi (Daenyth) - Saturday, 21 March 2009, 14:40 GMT
Comment by Marco (cipparello) - Saturday, 21 March 2009, 23:56 GMT
Hi Bill and Daenyth,
I opened the FR due to the fact that the arch scripts for boot & shutdown (rc.sysinit & rc.shutdown) and the daemon script that take care to mount and unmount network filesystems (netfs) aren't aware of the case that in the fstab could be declared also network block devices with a 'not network filesystem' (for example an iSCSI or AoE block devices with ext3 filesystem).

I post a portion of my fstab where I have various network block devices declared like these:

/dev/iscsi/ /mnt/lvbackup1 ext3 noauto,_netdev,defaults,relatime 0 0
/dev/iscsi/ /mnt/lvbackup1 xfs auto,_netdev,defaults 0 0

As you can see filesystems are ext3 and xfs and I've specified the '_netdev' option (see man mount) plus, the second, must be mounted automatically at startup ('auto' option).

With the patches attached the system is able to:

- rc.sysinit don't try to mount network filesystems (as now) AND network block devices because network interfaces aren't up yet

- The netfs daemon take care to mount and unmount network filesystems (as now) AND network block devices

- rc.shutdown don't try to unmount network block devices still mounted (this could be the case if something went wrong during the execution of netfs/iSCSI/AoE stop) and therefore avoid stopping the shutdown procedure.

The last script (rc.shutdown) is the only one that I modified just to avoid stopping the shutdown procedure that would require me to restart the server hardware.

I know that this feature is generally useful for server and not all the users need it but the patches don't affect anyone that don't use network block devices ('_netdev' option) therefore the initscripts behave as usual.

Thanks for any response or other solutions, I hope to be clear and may be useful to other.

Attached the patch versus the actual (2009.03-2) initscripts package.
Comment by Roman Kyrylych (Romashka) - Tuesday, 30 June 2009, 21:35 GMT
There is a problem with fuse and fuseblk filesystems - they are not necessarily network filesystems, but reside in $NETFS.
Comment by Aaron Griffin (phrakture) - Thursday, 30 July 2009, 17:22 GMT
Would someone mind explaining this a bit more? What are the pitfalls here? Does this break fuse as Roman suggests?
Comment by Aaron Griffin (phrakture) - Thursday, 30 July 2009, 17:29 GMT
Aha, looking at this a little more, what I gather is that it simply moves anything listed as a _netdev mount to the netfs daemon. Those mounts are skipped in sysinit/shutdown. Is this a correct reading of all this? If so, that sounds totally fine to me - Thomas?
Comment by Marco (cipparello) - Thursday, 30 July 2009, 17:55 GMT
Yes Aaron, the patch is intended for this reason. I attach my current up to date patch since now in my installation
I use to export either network block devices via iSCSI (mounted on client as 'ext3'/'ext4' fs type) and network filesystems via NFSv4 / GlusterFS
(mounted on client as 'nfs'/'glusterfs' fs type).

The management by netfs/rc.sysinit/rc.shutdown scripts of the _netdev parameter (compliant with the meaning of this option as in the manual of mount)
allows to manage network block devices; about 'fuse' also I believe, as specified by Roman, that should not reside in the list NETFS.

About the 'fuse.glusterfs' specified in the patch during the stop process of netfs script that is because glusterfs on client side mounts in this way
the network fs exported by a glusterfsd server.

Hope to be clear.

Comment by Roman Kyrylych (Romashka) - Thursday, 30 July 2009, 18:06 GMT
Sorry, I've misrepresented the changes made by patches! (23:35 is not a good time to examine patches :-P)
They don't break any existing behaviour and are safe to apply.

Here's a list of what's done without and with the patch:

1) rc.sysinit mounts all filesystems from fstab except those in NETFS (which includes fuse and fuseblk).
With the patch a filesystem that is not in NETFS list but has _netdev option in fstab won't be mounted too - this is OK.

2) rc.shutdown unmounts every filesystem except ramfs,tmpfs,sysfs,proc.
With the patch rc.shutdown does not try to unmount _netdev filesystems - which sounds good as explainedd in Description.

3) rc.d/netfs (un)mounts all partitions fstab that are of NETFS types (which includes fuse and fuseblk).
With the patch it additionally (un)mounts filesystems from fstab that have _netdev option specified.
Comment by Roman Kyrylych (Romashka) - Thursday, 30 July 2009, 18:11 GMT
Hehe, two new comments while I was writing mine. :-P
@Marco: yes, fuse filesystems don't really belong to NETFS and rc.d/netfs, but I don't feel a strong need to create $FUSEFS and rc.d/fusefs yet (though it does not seem obvious to include netfs in DAEMONS to get your fuse systems mounted).
Comment by Marco (cipparello) - Thursday, 30 July 2009, 18:16 GMT
Yes Roman, me too think that they don't belong to NETFS but since they gave me no problems I preferred to add rather than remove: if it's not broken ... don't fix eheh

About 'fuse.glusterfs' its an exception since I need to umount glusterfs filesistems but during the mount action of a device I need to specify 'glusterfs' as fs type but when mounted it appears as type 'fuse.glusterfs' since
glusterfs rely on fuse on client side.

Comment by Aaron Griffin (phrakture) - Thursday, 30 July 2009, 20:43 GMT
Well, what if we remove fuse from netfs, so they're mounted as normal. If it needs a network, you could add _netdev to fstab, right?

@Marco - I will be applying your patches soon
Comment by Aaron Griffin (phrakture) - Thursday, 30 July 2009, 20:51 GMT Comment by Aaron Griffin (phrakture) - Thursday, 30 July 2009, 20:53 GMT
Ignore the fact that I missed an "$rc -gt 0" check. Fixed that in the next commit
Comment by Thomas Bächler (brain0) - Thursday, 30 July 2009, 21:25 GMT
We added fuse/fuseblk to netfs, because "killing all processes" happens before "unmounting file systems". That way, the process of the fuse-program will be killed by killall5 instead of gracefully umounting.
Comment by Thomas Bächler (brain0) - Friday, 06 November 2009, 23:20 GMT
Hrm, why is this still open? Should be fixed, right?
Comment by Marco (cipparello) - Monday, 09 November 2009, 13:52 GMT
Yes Thomas, it was already fixed.