Red Hat Bugzilla – Bug 218237
NetworkManager position in startup and shutdown creates problems
Last modified: 2008-09-30 03:08:13 EDT
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
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):
always when trying to bring up services dependent on a "live" network.
Also problems on shutdown. Network is brought down before autofs and NFS mounts
are stopped causing hangs.
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
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
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
Problem still exists in rawhide as of today; updating version, CCing current
primary maintainer of NetworkManager
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.
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
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:
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
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.
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
> ... 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.
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.
Simple solution - remove NetworkManager shutdown from system shutdown list
(runlevel 6 or whatever?), and let it be terminated by the global kill.
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.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
NM stops at #84 now so this should be fixed in both f9 and f10.