Description of problem: After inserting my PCMCIA wireless card, udev spawns dhclient twice. Version-Release number of selected component (if applicable): udev-084-13 How reproducible: Every time Steps to Reproduce: 1. Insert Atheros-based PCMCIA card into laptop 2. ps -efH Actual results: % ps -efH (cut) root 408 1 0 11:47 ? 00:00:00 /sbin/udevd -d root 4118 408 0 13:51 ? 00:00:00 /sbin/udevd -d root 4122 4118 0 13:51 ? 00:00:00 /bin/bash /etc/sysconfig/network-scripts/ifup-eth /etc/sysconfig/netwo root 4254 4122 0 13:51 ? 00:00:00 /sbin/dhclient -1 -q -cf /etc/dhclient-ath0.conf -lf /var/lib/dhclie root 4119 408 0 13:51 ? 00:00:00 /sbin/udevd -d root 4125 4119 0 13:51 ? 00:00:00 /bin/bash /etc/sysconfig/network-scripts/ifup-eth /etc/sysconfig/netwo root 4243 4125 0 13:51 ? 00:00:00 /sbin/dhclient -1 -q -cf /etc/dhclient-ath0.conf -lf /var/lib/dhclie (cut) Expected results: Only spawn once.
Would have been more accurate to say that udev is spawning ifup-eth twice (as dhclient is invoked by this). As this is a wireless card, I'm surprised that it spawns this at all (I'd expect it to spawn ifup-wireless instead).
ifup-wireless is a secondary script, not a toplevel script. If you run udevmonitor, do you get one or two events?
Looks like two events: [root@shed david]# /usr/sbin/udevmonitor udevmonitor prints the received event from the kernel [UEVENT] and the event which udev sends out after rule processing [UDEV] UEVENT[1146049188.525938] add@/devices/pci0000:00/0000:00:1e.0/0000:02:04.0/0000:03:00.0 UEVENT[1146049188.525994] add@/class/net/wifi0 UEVENT[1146049188.526015] add@/class/net/ath0 UDEV [1146049188.582723] add@/devices/pci0000:00/0000:00:1e.0/0000:02:04.0/0000:03:00.0 UDEV [1146049188.590593] add@/class/net/wifi0 UDEV [1146049188.612935] add@/class/net/ath0
I think I meant to say "one event".
Actually I'm not sure what I meant. Possibly because Madwifi-ng uses both "wifi0" (for the hardware) and "ath0" (for individual instances), initscripts is having a problem with this.
Do you have both a wifi0 and ath0 ifcfg file with HWADDR in them, or only one? Does the updates-testing initscripts change the behavior at all?
I have these files: [david@shed ~]$ ll /etc/sysconfig/network-scripts/ifcfg-* -rw-r--r-- 3 root root 428 Apr 25 12:55 /etc/sysconfig/network-scripts/ifcfg-ath0 -rw-r--r-- 3 root root 214 Nov 3 15:02 /etc/sysconfig/network-scripts/ifcfg-eth0 -rw-r--r-- 1 root root 254 Jun 20 2001 /etc/sysconfig/network-scripts/ifcfg-lo -rw-r--r-- 3 root root 400 Nov 3 15:02 /etc/sysconfig/network-scripts/ifcfg-OneTel -rw-r--r-- 3 root root 337 Nov 3 15:02 /etc/sysconfig/network-scripts/ifcfg-rausb0 Maybe this file is interesting too: [david@shed modprobe.d]$ cat /etc/modprobe.d/madwifi alias wifi0 ath_pci alias ath0 ath_pci options ath_pci autocreate=sta [david@shed modprobe.d]$ rpm -qf /etc/modprobe.d/madwifi madwifi-0.0.0.20060317-4.lvn5 What's changed in the updates-testing initscripts? I'm reluctant to try it as I can't afford any downtime.
Actually, the updates-testing changes are unlikely to affect this. The problem is, you get two events (for wifi0 and ath0), and for each event, we look at the hardware address for the device that's added (it's the same in both cases). We then look for a config file that matches that hardware address, so we try to bring up ath0. In theory, dhclicent is supposed to prevent itself being brought up twice for the same device; I'll have to check that locking.
"The problem is, you get two events (for wifi0 and ath0), and for each event, we look at the hardware address for the device that's added (it's the same in both cases). We then look for a config file that matches that hardware address, so we try to bring up ath0." Could this be solved by initscripts spotting that: a) wifi0 has no wireless extensions and b) ifcfg-ath0 has details for a wireless device ?? [david@shed ~]$ /sbin/iwconfig lo no wireless extensions. eth0 no wireless extensions. sit0 no wireless extensions. wifi0 no wireless extensions. ath0 IEEE 802.11g ESSID:"(snip)" Nickname:"shed" Mode:Managed Frequency:2.462 GHz Access Point: (snip) Bit Rate:24 Mb/s Tx-Power:18 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Power Management:off Link Quality=44/94 Signal level=-51 dBm Noise level=-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
I've noticed that two dhclients are only spawned sometimes - other times, one notices that the other already exists. Some kind of race condition? Anyway, surely spotting that wifi0 has no wireless extensions and that ifcfg-ath0 is a wireless thingy ought to be sufficient?
The dhclient locking is certainly racy - but ideally initscripts shouldn't even try to run ifup twice; the code is probably not idempotent. Just filtering out devices without wireless extensions would break all wired ethernet devices, so we can't do that; and by the time wifi0 is added, ath0 might not be present yet if I understand the situation correctly. You should be able to workaround the problem by removing the HWADDR= line from ifcfg-eth0.
There isn't a visible "problem" that needs working around - everything "works". It's only running "ps" that tells me that there's some low-level defect that you guys have something you probably want to fix.
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
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.