NetworkManager is currently (in devel and F7) unusable with autofs and NFS mounts. This is because NetworkManager is stopped very early in the shutdown process (K02) and brings down the network with it. Then when autofs attempts to unmount any automounted nfs mounts, they fail because the remote machine is not accessible. Eventually the machine hangs trying to unmount the last nfs mounted directory. I suppose it might timeout eventually, but it's beyond my patience to wait that long.
Questions:
- Why is NetworkManager shutdown so early?
- Should autofs/nfs shutdown do a forced unmount if needed? Would that work?
- Do we need tighter NIS/autofs integration into NetworkManager?
On 8/16/07, Orion Poplawski orion@cora.nwra.com wrote:
NetworkManager is currently (in devel and F7) unusable with autofs and NFS mounts. This is because NetworkManager is stopped very early in the shutdown process (K02) and brings down the network with it. Then when autofs attempts to unmount any automounted nfs mounts, they fail because the remote machine is not accessible. Eventually the machine hangs trying to unmount the last nfs mounted directory. I suppose it might timeout eventually, but it's beyond my patience to wait that long.
Questions:
Why is NetworkManager shutdown so early?
Should autofs/nfs shutdown do a forced unmount if needed? Would that
work?
- Do we need tighter NIS/autofs integration into NetworkManager?
Moving forward we need much tighter integration with all NetworkManager and all network services on the machine. What I have done to reduce contention as well as boot time is to remove the following services from my init process
iscsi iscsid ntpd autofs sshd avahi-daemon avahi-dnsconfd yum-updatesd
They all now are started by custom scripts in /etc/NetworkManager/dispatcher.d. Yes I know that theoretically autofs doesn't below there because it can mount non network drives, but I don't use that so it is there now.
I can pass some of my stuff along if you are interested.
Jon
Am Donnerstag, den 16.08.2007, 14:43 -0400 schrieb Jon Nettleton:
On 8/16/07, Orion Poplawski orion@cora.nwra.com wrote: NetworkManager is currently (in devel and F7) unusable with autofs and NFS mounts. This is because NetworkManager is stopped very early in the shutdown process (K02) and brings down the network with it. Then when autofs attempts to unmount any automounted nfs mounts, they fail because the remote machine is not accessible. Eventually the machine hangs trying to unmount the last nfs mounted directory. I suppose it might timeout eventually, but it's beyond my patience to wait that long.
Questions: - Why is NetworkManager shutdown so early? - Should autofs/nfs shutdown do a forced unmount if needed? Would that work? - Do we need tighter NIS/autofs integration into NetworkManager?Moving forward we need much tighter integration with all NetworkManager and all network services on the machine. What I have done to reduce contention as well as boot time is to remove the following services from my init process
iscsi iscsid ntpd autofs sshd avahi-daemon avahi-dnsconfd yum-updatesd
They all now are started by custom scripts in /etc/NetworkManager/dispatcher.d. Yes I know that theoretically autofs doesn't below there because it can mount non network drives, but I don't use that so it is there now.
I can pass some of my stuff along if you are interested.
Jon
This all comes down to a failure of the init system to be smart enough though, doesn't it?
On 8/16/07, nodata lsof@nodata.co.uk wrote:
This all comes down to a failure of the init system to be smart enough though, doesn't it?
Is there potential use for oddjob here associated with network enabled services, so NetworkManager can talk over D-Bus to oddjob and run a set of network shutdown scripts?
-jef
On Thursday 16 August 2007 01:05pm, nodata wrote:
Am Donnerstag, den 16.08.2007, 14:43 -0400 schrieb Jon Nettleton:
[snip]
Moving forward we need much tighter integration with all NetworkManager and all network services on the machine. What I have done to reduce contention as well as boot time is to remove the following services from my init process
iscsi iscsid ntpd autofs sshd avahi-daemon avahi-dnsconfd yum-updatesd
They all now are started by custom scripts in /etc/NetworkManager/dispatcher.d. Yes I know that theoretically autofs doesn't below there because it can mount non network drives, but I don't use that so it is there now.
I can pass some of my stuff along if you are interested.
Jon
This all comes down to a failure of the init system to be smart enough though, doesn't it?
Not necessarily.
The rule of thumb is that the S and K number should add up to 100, but you don't absolutely *have* to do that. If NetworkManager really does need to start up so late, we should still have it stopped as late as possible in the shutdown process. If the S and K don't add up to 100 because of t hat, oh well.
However, I'm not sure that would entirely solve all the issues that are being discussed in this thread.
Jon Nettleton wrote:
Moving forward we need much tighter integration with all NetworkManager and all network services on the machine. What I have done to reduce contention as well as boot time is to remove the following services from my init process
iscsi iscsid ntpd autofs sshd avahi-daemon avahi-dnsconfd yum-updatesd
They all now are started by custom scripts in /etc/NetworkManager/dispatcher.d. Yes I know that theoretically autofs doesn't below there because it can mount non network drives, but I don't use that so it is there now.
I can pass some of my stuff along if you are interested.
I'd be interested.
On 8/22/07, Orion Poplawski orion@cora.nwra.com wrote:
Jon Nettleton wrote:
Moving forward we need much tighter integration with all NetworkManager and all network services on the machine. What I have done to reduce contention as well as boot time is to remove the following services from my init process
iscsi iscsid ntpd autofs sshd avahi-daemon avahi-dnsconfd yum-updatesd
They all now are started by custom scripts in /etc/NetworkManager/dispatcher.d. Yes I know that theoretically autofs doesn't below there because it can mount non network drives, but I don't use that so it is there now.
I can pass some of my stuff along if you are interested.
I'd be interested.
http://www.hekanetworks.com/~jnettlet/open-source/dispatcher.d.tar.bz2
that is my whole directory. Right now if I don't want the dispatcher to work with a service I just drop them in the off directory. All of them are just variations on the original script posted to this list some time ago.
Jon
Dnia 16-08-2007, Cz o godzinie 11:52 -0600, Orion Poplawski napisał(a):
NetworkManager is currently (in devel and F7) unusable with autofs and NFS mounts. This is because NetworkManager is stopped very early in the shutdown process (K02) and brings down the network with it. Then when autofs attempts to unmount any automounted nfs mounts, they fail because the remote machine is not accessible. Eventually the machine hangs trying to unmount the last nfs mounted directory. I suppose it might timeout eventually, but it's beyond my patience to wait that long.
There is similar NFS issue when switching networks with ~ on NFS. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199536
Wired IP is released before wireless IP is acquired. This cause a window of network shortage, which in turn make user's ~ (and gconf settings) unavailable. Both problems show NetworkManager problems in IP address management.
On Tue, 2007-08-21 at 13:40 +0200, Tomasz Torcz wrote:
Dnia 16-08-2007, Cz o godzinie 11:52 -0600, Orion Poplawski napisał(a):
NetworkManager is currently (in devel and F7) unusable with autofs and NFS mounts. This is because NetworkManager is stopped very early in the shutdown process (K02) and brings down the network with it. Then when autofs attempts to unmount any automounted nfs mounts, they fail because the remote machine is not accessible. Eventually the machine hangs trying to unmount the last nfs mounted directory. I suppose it might timeout eventually, but it's beyond my patience to wait that long.
There is similar NFS issue when switching networks with ~ on NFS. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199536
Wired IP is released before wireless IP is acquired. This cause a window of network shortage, which in turn make user's ~ (and gconf settings) unavailable. Both problems show NetworkManager problems in IP address management.
The problem of NetworkManager is that it does not have _any_ grace period on wired or wirelss disconnections. If you pull the eth0 plug for a few seconds it immediately disables the interfaces and when you plug it in it will acquire a possibly new IP address via dhcp. NM should be more tolerant of disconnections, not remove the IP immediately and try to reset previous values if the wired interface comes back in a very short period of time (I say up to 60sec. at least). It is very annoying to loose all connections when all it happened is someone removed a patch for a few second from the patch panel while working on it.
Simo.
-
Jef Spaleta -
Jon Nettleton -
Lamont R. Peterson -
nodata -
Orion Poplawski -
Simo Sorce -
Tomasz Torcz