FS#13622 - [initscripts] Network daemon gets stopped before netfs.

Attached to Project: Arch Linux
Opened by Jordy van Wolferen (jordz) - Sunday, 01 March 2009, 23:34 GMT
Last edited by Roman Kyrylych (Romashka) - Saturday, 03 October 2009, 13:44 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
I disabled netfs in rc.conf.
I started netfs manually after my system was up and running.
When I shutdown my system, the network daemon gets stopped before netfs.
So it can't umount and you need to hard reset.

Steps to reproduce:
- Disable netfs in rc.conf
- Start netfs when you're system is running
- Shutdown
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Saturday, 03 October 2009, 13:44 GMT
Reason for closing:  Fixed
Comment by Alessandro Doro (adoroo) - Monday, 02 March 2009, 18:29 GMT
In rc.shutdown first are stopped the daemons specified in rc.conf then the leftover daemons by checking /var/run/daemons.
The $DAEMONS loop seems superfluous and redundant. It should suffice going through /var/run/daemons in reverse mtime order.
Comment by Aaron Griffin (phrakture) - Monday, 02 March 2009, 19:25 GMT
The mtime order won't suffice either - a simple "/etc/rc.d/network restart" gets us back in the same situation you have now.

I remember another bug report about the same thing...
Comment by Allan McRae (Allan) - Saturday, 21 March 2009, 00:02 GMT
Maybe we should shutdown any daemons in /var/run/daemons that are not in our DAEMONS array first but I am not sure how that could be done.

Edit: given we have nice file names in /var/run/daemons, this would be achievable. But it could still stop daemons on the wrong order so only a partial fix
Comment by Thomas Bächler (brain0) - Wednesday, 27 May 2009, 05:05 GMT
I would consider removing netfs from DAEMONS a user error (even if you have no net filesystems in fstab). Once it is removed, we cannot guarantee proper shutdown order anymore, period.

One of the reasons for having netfs is so that we can umount net filesystems early on shutdown. Removing it is like saying "I don't WANT net filesystems to be umounted properly". I suggest a "Won't fix".
Comment by Thomas Bächler (brain0) - Wednesday, 27 May 2009, 05:07 GMT
Another note: Don't start netfs manually. Instead, mark the filesystems "noauto" in fstab and mount them manually later. The netfs script is no replacement for writing your own convenience scripts for such things.
Comment by Phillip Smith (fukawi2) - Wednesday, 27 May 2009, 05:18 GMT
While I agree with Thomas to an extent, could the network script be modified to either call `netfs stop` or to do the same things the netfs script does? IMHO, part of the `network` daemon's job should be to ensure that the rest of the system, or at least the kernel, is aware that the network is going away and unmounting file systems that rely on the network could (should?) be part of this.
Comment by Allan McRae (Allan) - Wednesday, 27 May 2009, 05:22 GMT
Then what about those people who use the networkmanager daemon rather than the network one? One tool, one job...
Comment by Phillip Smith (fukawi2) - Wednesday, 27 May 2009, 05:28 GMT
Yes, there would be some disparity, but I still think (and I did say this is JMHO ;)) that if something (network daemon or networkmanager etc) is taking away network connectivity, then it would be a matter of simple courtesy to make sure that at least the kernel isn't relying on the network for anything, especially something that could cause stability problems (ie, a hard-mounted network file system).
Comment by Aaron Griffin (phrakture) - Thursday, 30 July 2009, 16:52 GMT
Does this help?
http://projects.archlinux.org/?p=initscripts.git;a=commitdiff;h=7f1bd75ee6aaffddf47e704c46fbab5396b7dd19
Comment by Jordy van Wolferen (jordz) - Thursday, 30 July 2009, 20:40 GMT
Thank you very much, it works perfectly now!

Loading...