Bug 542078 - NM starting too late due to erroneous hal dependency
Summary: NM starting too late due to erroneous hal dependency
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-28 09:09 UTC by Terry Barnaby
Modified: 2010-01-02 21:27 UTC (History)
4 users (show)

Fixed In Version: 0.2.997-4.git20091218.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-02 21:27:49 UTC
Type: ---


Attachments (Terms of Use)

Description Terry Barnaby 2009-11-28 09:09:08 UTC
Description of problem:
If the NetworkManager service is running but not managing the current network connection (The network service manages eth0 at boot for example), then firefox starts up in Offline mode.
This bug could be in NetworkManager ?


Version-Release number of selected component (if applicable):
Fedora/3.5.5-1.fc12

How reproducible:
Solid

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Rakesh Pandit 2009-11-28 09:55:55 UTC
I would like firefox default behavior to be 

"to get offline only if host is not able to reach network via NM or any other way (configured by say wvdial etc)"

Thanks,

Comment 2 Felix Schwarz 2009-11-28 21:32:21 UTC
IMHO this is not a bug in Firefox but a general issue in NetworkManager.
See this Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/191889

A workaround for Firefox is to disable the NetworkManager integration: 'toolkit.networkmanager.disable' in about:config. However the problem affects many other applications like Empathy, Pidgin, ...

Hard to believe that there is no other bug in bz...

Comment 3 Rakesh Pandit 2009-11-29 07:05:01 UTC
Thanks for input but it is not a bug in NM as it is the application which gets offline. Moreover I know of this workaround, but it is a PITA for our users. If one machine is connection to internet via any method applications are supposed to figure that out. So, it is a bug.

Regards,

Comment 4 Terry Barnaby 2009-11-29 09:01:22 UTC
I guess if NetworkManager is being touted as the system to manage networking in Fedora and other Linux's in the future, then it should be used as the API to find out if the networking in the system is up rather than have the applications all duplicating this functionality. If that is the case then I would have thought that the "bug" was in NM and/or its API ?

Comment 5 Felix Schwarz 2009-11-29 13:16:42 UTC
Technically I think it is not a bug but a glitch in the API. IMHO there are two different views on that topic:
1. NetworkManager provides an API which tells if NM controls a connection which is active. 

=> A lot of applications use this API the wrong way (Firefox, Empathy, Pidgin, ...) because they don't do additional checks.

=> From an app authors point of view, the NM api is useless because you can not rely on it.

=> Another project should come up providing this API which also cares about other connections.

2. The NM API should reflect the system's state of 'being online'.

=> The implementation needs to care about externally configured connections.

So it depends on the authors of NetworkManager which philosophy is correct.

Comment 6 Dan Williams 2009-11-29 23:29:54 UTC
(In reply to comment #5)
> Technically I think it is not a bug but a glitch in the API. IMHO there are two
> different views on that topic:
> 1. NetworkManager provides an API which tells if NM controls a connection which
> is active. 
> 
> => A lot of applications use this API the wrong way (Firefox, Empathy, Pidgin,
> ...) because they don't do additional checks.

If NM is running, NM is meant to control the default internet connection.  If NM cannot control the default internet connection, you may not want to use NM at all.

> => From an app authors point of view, the NM api is useless because you can not
> rely on it.

If people are using NM correctly, then the NM API is consistent and correct, and it will reflect all details about the network connections of the machine.  When people bring up network devices that NM doesn't know about, then obviously NM won't have a good picture of the network situation of the machine.

> => Another project should come up providing this API which also cares about
> other connections.
> 
> 2. The NM API should reflect the system's state of 'being online'.

NM reflects the network state of the machine for the devices it is controlling.  If a device cannot be controlled by NM, then we add the functionality to NM to control that device.

The real issue here is why the reporter's 3G modem does not reliably connect.  Reporter, can you do the following when you have problems?

1) service NetworkManager stop
2) killall -TERM modem-manager
3) modem-manager --debug
4) service NetworkManager start
5) reproduce your issue, and attach the modem-manager debug output here

Thanks!

Comment 7 Terry Barnaby 2009-11-30 09:50:02 UTC
I am not using a G3 modem and the network connection is not just the internet it is a local network LAN connection that also servers the internet.
Most of my systems use a local network server which provides NIS and /home and /data using NFS. I normally use the service "network" to bring up wired or wireless networking for this. Fedora, by default, uses NetworkManager to manage all network devices though. I use the service "network" as, for some reason, the NetworkManager service is started after the netfs and other services are started. Is there a reason for this ??

I can obviously turn of the NetworkManager service, which I have done on the desktop systems. However, I also have a few Laptops that can roam. In F11 and before I have used the network and NetworkManager services. When the laptop boots away from home, the "network" service fails and I can then use the NetworkManager service to connect to whatever wireless network or G3 network is available.

It does seem sensible to me that the "system" provides applications with info on if the network is up (not just the Internet). The NetworkManager service seems the place to do this and the applications are starting to use it for this purpose.
So maybe a NM "isNetworkUp()" API call is called for ?

Comment 8 Dan Williams 2009-11-30 18:54:04 UTC
I replied on the mailing list; copied here for posterity.

------
No particular reason, in fact that looks like a bug.  NM no longer
depends on HAL, but that dependency is still in the initscript, which
looks like it pushes NM later than netfs.

But in reality, you're looking for a dependency based initsystem which
we don't quite yet have.  There are already scripts that kick netfs to
mount stuff when NM brings the network up
(/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous
bootup *and* your mounts.  The rest of the system, if it requires
something from the mounted directories, needs to be smart enough to know
that.

If you need to, you can set NETWORKWAIT=yes in /etc/sysconfig/network,
which causes the NetworkManager initscript to block until a network
connection is brought up, or 30 seconds have passed.
------

The erroneous haldaemon initscript dep is fixed in upstream commit:

bde54958a9fa3860c4f2548321e9ec49e66d9dca

and will make it's way to an F12 update soon.  Beyond that, you can simulate this fix by making this change to /etc/init.d/NetworkManager:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=bde54958a9fa3860c4f2548321e9ec49e66d9dca

and then:

chkconfig NetworkManager resetpriorities
chkconfig NetworkManager on
chkconfig network off

and then lets see where we get.  The network may not be up yet by the time netfs starts initially, but when the network does come up (which should be quite soon after) netfs will get kicked by /etc/NetworkManager/dispatcher.d/05-netfs and your stuff should get mounted.  If you have things that depend on the mounts and isn't smart enough to wait until the mounts appear, then you can set NETWORKWAIT as I noted above to make the boot process block until the network is up.

Comment 9 Terry Barnaby 2009-11-30 19:53:15 UTC
Hi, Thanks for the info.
I would have thought that a generic isUp() is good enough for the likes
of Firefox and Pidgen though to decide if to start offline. Being connected to a Network is probably all you need, you may be accessing an Intranet as all
my systems Firefox home pages do ...

Anyway, following your email (And notes in Bugzilla) I thought I'd try and
use NM properly for my config. However I have a problem, which may be
a bug. I have turned off the Network services and turned on NetworkManger.
I have two main network interfaces eth0 (wired) and eth1 (Wifi), both are
set to be managed by NM and to start at boot. I have also added
NETWORKWAIT=yes in /etc/sysconfig/network.

When I boot with this the network (eth1 (eth0 is disconnected)) does not
come up at boot. There is a message stating a failure on the line
where it is waiting for the network to come up. When I log in as a
local user the network then comes up ...

I also note that, before the user is logged in, I cannot start the network
with "service network start" and the WiFi light is off. It looks like
NM has done something like powered down my WiFi chip ?
(Intel Corporation PRO/Wireless 2915ABG IBM Thinkpad R52)

Another thing, I would need NETWORKWAIT=yes as I have ypbind enabled.
Maybe ypbind should be modified to not start when the network is down and
also added to /etc/NetworkManager/dispatcher.d ?

Comment 10 Terry Barnaby 2009-11-30 20:30:52 UTC
Hi I note my title of:
"F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web" has been changed ?
This is the original bug, should I open a new bug report under that title
on NetworkManager or Firefox ?

Comment 11 Dan Williams 2009-12-01 09:04:46 UTC
(In reply to comment #10)
> Hi I note my title of:
> "F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't
> browse the Web" has been changed ?
> This is the original bug, should I open a new bug report under that title
> on NetworkManager or Firefox ?  

No, because it's not a bug, it's a misconfiguration issue.  If you're not using NM to control the primary internet connection, then NM should be turned off with chkconfig and Firefox will then be oblivious to any network changes.  But if you are using NM to control the primary internet connection (and we've been trying to debug that via the mailing lists, thanks!) then we should figure out why that's not working correctly here.

Comment 12 Fedora Update System 2009-12-08 08:23:20 UTC
NetworkManager-0.7.997-1.fc12,ModemManager-0.2.997-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.997-1.fc12,ModemManager-0.2.997-1.fc12

Comment 13 Fedora Update System 2009-12-10 04:23:56 UTC
NetworkManager-0.7.997-1.fc12, ModemManager-0.2.997-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager ModemManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13012

Comment 14 Terry Barnaby 2009-12-10 20:16:41 UTC
This update has fixed the problem and also fixed the NIS problem:
"domainname: you must be root to change the domain name".

Thanks to all who worked on this.

Terry

Comment 15 Fedora Update System 2009-12-14 22:48:49 UTC
NetworkManager-0.7.997-2.git20091214.fc12,ModemManager-0.2.997-2.git20091214.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.997-2.git20091214.fc12,ModemManager-0.2.997-2.git20091214.fc12

Comment 16 Fedora Update System 2009-12-16 01:08:23 UTC
NetworkManager-0.7.997-2.git20091214.fc12, ModemManager-0.2.997-2.git20091214.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager ModemManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13165

Comment 17 Fedora Update System 2009-12-18 04:26:22 UTC
ModemManager-0.2.997-3.git20091216.fc12, NetworkManager-0.7.997-2.git20091214.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ModemManager NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13165

Comment 18 Fedora Update System 2009-12-22 04:48:49 UTC
ModemManager-0.2.997-4.git20091218.fc12, NetworkManager-0.7.997-2.git20091214.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ModemManager NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13165

Comment 19 Fedora Update System 2010-01-02 21:27:03 UTC
ModemManager-0.2.997-4.git20091218.fc12, NetworkManager-0.7.997-2.git20091214.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


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