Summary: | NM starting too late due to erroneous hal dependency | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Terry Barnaby <terry1> |
Component: | NetworkManager | Assignee: | Gecko Maintainer <gecko-bugs-nobody> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 12 | CC: | dcbw, fschwarz, gecko-bugs-nobody, rpandit |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 0.2.997-4.git20091218.fc12 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-01-02 21:27:49 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: |
Description
Terry Barnaby
2009-11-28 09:09:08 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, 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... 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, 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 ? 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. (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! 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 ? 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. 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 ? 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 ? (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. 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 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 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 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 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 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 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 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. |