From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2) (KHTML, like Gecko) Description of problem: My (Dell Inspiron 515) laptop contains a broadcom Ethernet card, and I also have a Netgear WG511T wireless Cardbus card, which is Atheros based. I have madwifi drivers installed, but I don't use the card at the moment. When editing the eth0 settings (changing from DHCP to static - in order to get into the 169.254. range to speak to a friend's computer via crossover), after pressing save, the application just hangs. The change gets written out to the filesystem, so I just kill system-config-network and forget about it. Quite annoying though. This only began happenning recently, so I'm flummoxed. i.e., all the time I was setting up my networking I had no problems. Maybe some new package has conflicted? I'm clueless. Version-Release number of selected component (if applicable): 1.3.17-0.FC2.1 How reproducible: Always Steps to Reproduce: 1. Edit eth0 settings 2. Save Actual Results: Hangs Expected Results: Doesn't hang Additional info:
I think I remember when the problem began, now; when I added the host list to /etc/hosts from http://everythingisnt.com/hosts.html My /etc/hosts looks like this: >>> # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 192.168.1.1 adsl 192.168.1.2 study 192.168.1.3 shed-wifi 192.168.1.4 shed shed-eth 192.168.1.5 corner 192.168.1.254 ceiling # This Hosts file has been altered to block ad servers. # To restore the file just # delete everything below the first entry or rename hosts.nbk # to hosts and move it to the proper directory. # Updated: Datestamp below # This is an ad blocking hosts file compiled by # Mike Skallas(user245(at)hotmail.com) # Available at http://everythingisnt.com/hosts.html # Copyright 2000-2004. Please do not redistribute, use above link. # Free only for Residential/Non-Profit use. # Just add '127.0.0.1 ADSERVER' to the bottom to continue the list. 127.0.0.1 www.doubleclick.net 127.0.0.1 ad.doubleclick.net #remove this for atomfilms problems 127.0.0.1 ad.preferences.com 127.0.0.1 ads.doubleclick.com (etc.) <<< In system-config-network, only the first set of 192.168.0. stuff shows up in the hosts tab. Here's what I get when I strace the hung process: # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 192.168.1.1 adsl 192.168.1.2 study 192.168.1.3 shed-wifi 192.168.1.4 shed shed-eth 192.168.1.5 corner 192.168.1.254 ceiling # This Hosts file has been altered to block ad servers. # To restore the file just # delete everything below the first entry or rename hosts.nbk # to hosts and move it to the proper directory. # Updated: Datestamp below # This is an ad blocking hosts file compiled by # Mike Skallas(user245(at)hotmail.com) # Available at http://everythingisnt.com/hosts.html # Copyright 2000-2004. Please do not redistribute, use above link. # Free only for Residential/Non-Profit use. # Just add '127.0.0.1 ADSERVER' to the bottom to continue the list. 127.0.0.1 www.doubleclick.net 127.0.0.1 ad.doubleclick.net #remove this for atomfilms problems 127.0.0.1 ad.preferences.com 127.0.0.1 ads.doubleclick.com
Oops - _this_ is what I get when I strace the hung process: [root@shed david]# strace -p 4362 Process 4362 attached - interrupt to quit futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 futex(0x9c84998, FUTEX_WAKE, 1) = 0 ... and so on ...
hmm... could you trace it with gdb and post the backtrace? # gdb <pid> /usr/bin/python > bt
Created attachment 104712 [details] gdb backtrace Backtrace attached as requested.
hmm, is it possible, that you start system-control-network, the press the button "Configure", close the old system-control-network windows and work with the system-config-network after that?
I normally load system-config-network by typing "system-config-network" at a terminal, or from the Start menu... is that the information you're asking for? (I suspect we have different first langauges!) Whichever way I load it (including the way you mention), it still hangs on save.
Created attachment 105133 [details] My previous /etc/sysconfig/networking/profiles/default/hosts I discovered that /etc/sysconfig/networking/profiles/default/hosts was a 699K file from a previous ad-blocker hosts file I had been using... I deleted this, and copied /etc/hosts, a 32K ad-blocker hosts file. This fixed it. My guess is that it was just taking an enormously long time to process... some optimization needed? It still takes about 10 seconds to do a save (on a Pentium 4 2.8Ghz 512Mb RAM) with the 32K file, so I guess that the 699K file was just taking forever (bad algorithm in the code somewhere?) Are /etc/sysconfig/networking/profiles/default/hosts and /etc/hosts meant to have the same inode? Mine didn't, probably because I'd manually moved/edited them.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
This issue still exists in FC4 - i.e., if you have a large /etc/hosts file, then system-config-network takes an inordinately long time to process it when saving. My present /etc/hosts file is 32K, and I've just timed that it takes s-c-n 19 seconds (on a Pentium 4 mobile 2.8GHz) to do a "Save" operation.
This bug blocks 87718? What is 87718? 87718 is not authorized for public viewing, but the ones around it are from 1st April 2003. The number of bugs blocking 87718 is huge - is it some kind of tracker? https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&component_text=&query_format=advanced&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=blocked&type0-0-0=substring&value0-0-0=87718&field1-0-0=noop&type1-0-0=noop&value1-0-0=
yep... a tracker... don't worry...
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Still exists.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're 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.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp