|Summary:||NetworkManager position in startup and shutdown creates problems|
|Product:||[Fedora] Fedora||Reporter:||Michal Jaegermann <michal>|
|Component:||NetworkManager||Assignee:||Dan Williams <dcbw>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||9||CC:||amlau, bbaetz, clydekunkel7734, cra, dcbw, fedora, orion, pjs1, tmz, triage, tvujec|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-09-30 02:00:49 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Michal Jaegermann 2006-12-03 23:47:18 UTC
Description of problem: Assume a machine on a network with a dynamic IP assignment where a network interface, even wired, is handled by NetworkManager. This activates network connection only at the very end of the whole startup sequence while there is a number of service which need that already. For example, if there are some network file systems to mount, NFS or SMB, then this fails with a lengthy timeout. Similarly on a shutdown you are getting nastygrams when we are trying umount those file systems but a network is already gone. Other services adversely affected will include, for example, syslog - S12 - if you have any network logging autofs - S28 - if '/net -hosts' is turned on and/or a central master map, with +auto.master, exist cups - S55 - if we have IPP printers to find ntpd - S58 - pretty obvious, although this can (possibly even should) be started async - see bug 216351 for a possible method to do that sendmail - S80 - if we need to contact a name server for a proper startup avahi-daemon - S98 - "The daemon registers local IP addresses" but there are none so far and avahi-dnsconfd will have problems too as well according to its man page. These are the first things which come to mind. Are there real reasons why NetworkManager needs to be brought up so late instead of placing that service between "network" and "syslog"? Version-Release number of selected component (if applicable): NetworkManager-0.6.4-5.fc6 How reproducible: always when trying to bring up services dependent on a "live" network.
Comment 1 Orion Poplawski 2007-08-22 15:45:57 UTC
Also problems on shutdown. Network is brought down before autofs and NFS mounts are stopped causing hangs.
Comment 2 Tomislav Vujec 2007-10-05 06:19:45 UTC
Starting NM earlier might help, but many of the old applications and daemons will actually require a restart if network environment changes or disappears for longer periods of time. And this is just the use case which NM handles the best, signaling network availability and making sure that you stay online whenever possible. This behavior caused a lot of problems in the past, with almost every network application being unable to gracefully handle network changes. However, in the past couple of years the situation changed dramatically. Many apps are now either relying on NM messages to switch offline (gracefully!), or are just better at handling network as optional resource. cups use to crash like crazy, while now days I can see available printers almost immediately after connecting. Evolution used to lost the state, and depend on manual switching to offline before disconnecting. One might argue that the rest of applications should do that too. E.g. syslog should be able to keep the log in a buffer and wait for the network to become available before dumping it, avahi already dynamically registers interfaces as they become available, etc. NFS is a really problematic one. Especially if some of the system services require NFS stored data, or if user wants to mount his home directory over network. However, since the NFS really treats the network as a required and reliable rather than optional and unreliable service, most NM use cases would be inapplicable. Finally, NM needs both D-BUS and hal, and they would need to be started earlier as well. Further more, in the DNS caching scenario (which is responsible for many applications being able to handle network change gracefully), NM needs named too.
Comment 3 Thorsten Leemhuis 2007-10-26 15:49:22 UTC
Problem still exists in rawhide as of today; updating version, CCing current primary maintainer of NetworkManager
Comment 4 Bug Zapper 2008-04-04 05:05:17 UTC
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
Comment 5 Michal Jaegermann 2008-04-04 16:22:06 UTC
Recently I have seen complaints from somebody with cifs mounts specified in /etc/fstab. A habit of killing network connections on a termination of desktop sessions, which NetworkManager aquired with F8, makes things much worse. I am not sure what is a way out. Make all services which require a network presence aware that a network may be gone in any moment? The current ntpd seems to cope. What one can do with network mounts of any kind I have no idea. Everything of that sort through dbus somehow? Closing that bug sound like way premature.
Comment 6 Charles R. Anderson 2008-04-08 14:46:01 UTC
I usually manually mount a CIFS filesystem after I log in. If I leave it mounted and shut down, the shutdown process tried to unmount the filesystem long after NetworkManager has taken the interface down, causing it to hang for a couple minutes.
Comment 7 Michal Jaegermann 2008-04-08 15:59:07 UTC
> ... causing it to hang for a couple minutes. That is what you have to expect in the current situation. You may try to configure autofs, with a short timeout, to do the job and _hope_ that by the time a network goes down that network file system was already unmounted. Works, sort of, with NFS. The last time I had an opportunity to try that with CIFS there were some troubles with it but this was a while ago and possibly they were sorted out.
Comment 8 Clyde E. Kunkel 2008-04-12 18:36:05 UTC
I have a CIFS mount on a rawhide test system that takes about 45 seconds to umount during shutdown or restart. If I ctrl-alt-f7, I see the Unmounting CIFS filesystems msg displayed there and the wait begins. I also see that network manager daemon is first service to be stopped and the dispatcher is the 5th. Unmounting the cifs file is about number 20 or so. Shouldn't network manager first umount any network files before it closes the interface? Maybe related or not is that the CIFS filesystem mount fails during init when the fstab mounts are made, but ends up being mounted at some other point before the desktop settles in.
Comment 9 Colin Walters 2008-04-23 20:35:20 UTC
Simple solution - remove NetworkManager shutdown from system shutdown list (runlevel 6 or whatever?), and let it be terminated by the global kill.
Comment 10 Orion Poplawski 2008-04-23 21:46:49 UTC
NM segfaults and spews output to console during shutdown after dbus is stopped: Apr 23 15:42:28 bona NetworkManager: <info> disconnected by the system bus. Apr 23 15:42:28 bona NetworkManager: dbus_g_connection_register_g_object: assert ion `connection != NULL' failed Apr 23 15:42:28 bona nm-system-settings: disconnected by the system bus. So, while it "works", it ain't pretty.
Comment 11 Bug Zapper 2008-05-14 02:29:23 UTC
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Dan Williams 2008-09-30 01:14:59 UTC
NM stops at #84 now so this should be fixed in both f9 and f10.