Bug 218237 - NetworkManager position in startup and shutdown creates problems
NetworkManager position in startup and shutdown creates problems
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-03 18:47 EST by Michal Jaegermann
Modified: 2008-09-30 03:08 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-29 22:00:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-12-03 18:47:18 EST
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 11:45:57 EDT
Also problems on shutdown.  Network is brought down before autofs and NFS mounts
are stopped causing hangs.
Comment 2 Tomislav Vujec 2007-10-05 02:19:45 EDT
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 11:49:22 EDT
Problem still exists in rawhide as of today; updating version, CCing current
primary maintainer of NetworkManager
Comment 4 Bug Zapper 2008-04-04 01:05:17 EDT
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 12:22:06 EDT
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 10:46:01 EDT
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 11:59:07 EDT
> ... 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 14:36:05 EDT
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 16:35:20 EDT
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 17:46:49 EDT
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-13 22:29:23 EDT
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-29 21:14:59 EDT
NM stops at #84 now so this should be fixed in both f9 and f10.

Note You need to log in before you can comment on or make changes to this bug.