Bug 557836

The order is handled by the start-up scripts themselves, not related to bootloader.

IMHO we see wrong dependencies between nfs and network script.
Next point is that there exists two scripts network and network-remotefs
to avoid such problems ... IMHO you have a setup/configuration problem
on your system between network interfaces required for remotefs and
any other network interface.  AFAICT you the network-remotefs depends
on $remote_fs which is nfs and smbfs, that is that network interfaces
enabled with network-remotefs will be stopped before nfs whereas
network interfaces enabled with the network script will be stopped
*after* nfs.

But maybe I'm wrong therefore I reassign this to the maintainer of the
package sysconfig as both network and network-remotefs are part of this
package (Hi Marius).  Also I'm adding the maintainer of the package
nfs-client (Hi Neil) together with my own to the carbon copy list.

(In reply to comment #0)
> 2. I use Network manager to manage my network connection, not sure it happens
> with traditional ifup.

The behaviour is correct -- it will not work as it is configured.

As Werner already described, there are two network scripts involved.
The start order is:

/etc/init.d/network          -- requires only local-fs, sets up _ifup_
                                interfaces supported for $remote_fs (=nfs)

/etc/init.d/nfs              -- requires $network (network), mounts nfs;
                                that is, implements/provides $remote_fs

/etc/init.d/network-remotefs -- requires $remote_fs, starts NetworkManager

The stop order is: network-remotefs, nfs, network

When ifup is in use, /etc/init.d/nfs will work over normal ethernet,
bridge, bonding, vlan interfaces, but not over wlan, ppp, tunnels...

You can not mount via /etc/init.d/nfs and use NetworkManager.
The NetworkManager can not be started via network script, because it
requires $remote_fs -- it is installed on /usr that maybe on nfs.

To mount nfs when NetworkManager is in use, it is required to disable
nfs using "insserv -r /etc/init.d/nfs" and start it (mount) via NM
dispatcher, that is via /etc/NetworkManager/dispatcher.d ...
AFAIS, there is a nfs dispatcher script -- but it expects enabled nfs;
this looks like it will not work... same with the autofs dispatcher...
It also restarts/stops with every interface up/down...
A mechanism like "man 5 ifservices" for ifup would be required here...

NM issue => Tambet.

Thanks for clarifying the situation.  So using nfs with networkmanager seems to be impossible in the current state.

This might be a stupid question, but is there a use case for having /usr on nfs and still be using network manager to handle network connections?

Also, isn't it possible to check if /usr is on a nfs mount and only then delay starting of network manager after $remote_fs?

NetworkManager is dynamic, so when using it, that should be taken into consideration. For example, the nfs dispatcher script we ship does not (and can not!) make much sense. A network connection isn't necessarily THE network connection. So that's why the nfs dispatcher script doesn't even attempt to mount any network file systems - there's simply no information available on the system that ties mounts to networks.

The dispatcher scripts however get all the information about network status, including connection's UUID, name, IP information etc. So it would be pretty easy to determine what configuration to use depending on active network (network file systems, printers, firewall, ....). The problem is, we don't have a UI tool to configure any of this.

As for this bug's summary, that also works as designed - it's generally impossible to execute "network deactivated" scripts before the connection is deactivated because in many cases (wifi disconnect due to weak signal, ethernet cable pulled out) it's just not known ahead of time (and no, having two sets of "network deactivated" scripts isn't a step in the right direction). (There are other problems with running user scripts before device deactivation as well.)

So that leaves only the "soft" NFS mount option. Which sort of makes sense to me - if network configuration is dynamic, so should be the used network services... I'm going to close this bug as WONTFIX because it is not possible to guarantee that network deactivation scripts always get run before network devices get deactivated.

From the manual page nfs(5):

soft / hard    Determines the recovery behavior of the NFS client after  an
               NFS  request  times out.  If neither option is specified (or
               if the hard option is specified), NFS requests  are  retried
               indefinitely.  If the soft option is specified, then the NFS
               client fails an NFS request  after  retrans  retransmissions
               have been sent, causing the NFS client to return an error to
               the calling application.

               NB: A so-called "soft" timeout can cause silent data corrup-
               tion  in  certain  cases.  As such, use the soft option only
               when client  responsiveness  is  more  important  than data
               integrity.   Using  NFS  over TCP or increasing the value of
               the retrans option may mitigate some of the risks  of  using
               the soft option.

IMHO the network interface used for NFS for /usr should *not* depend on
NetworkManager as /usr is not dynamic but NetworkManager.

i made a workaround for this problem, at least for smbfs/cifs shares.

look at bug #487190 comment #7.

i just removed the /sbin/chkconfig, and this did the trick for me.

now i have smbfs/cifs-shares even with networkmanager.

*** Bug 568303 has been marked as a duplicate of this bug. ***