Bug 502080

Summary: udev attempts to ifup-eth wlan0 upon resume from suspend
Product: [Fedora] Fedora Reporter: James Ralston <ralston>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: harald, notting, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-26 16:35:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Ralston 2009-05-21 19:00:57 UTC
I'm running Fedora 11 Preview on my laptop. I am *not* using NetworkManager:

$ /sbin/chkconfig | grep -i network
NetworkManager  0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off

Only the loopback is configured to be active on boot:

$ grep ONBOOT /etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network-scripts/ifcfg-eth0:ONBOOT=no
/etc/sysconfig/network-scripts/ifcfg-lo:ONBOOT=yes
/etc/sysconfig/network-scripts/ifcfg-wlan0:ONBOOT=no

But when I suspend my laptop, and then resume it, udev attempts to bring up the wlan0 interface:

$ ps fax
...
  218 ?        S<s    0:00 /sbin/udevd -d
 7785 ?        S<     0:00  \_ /sbin/udevd -d
 7795 ?        S<     0:00      \_ /bin/bash /etc/sysconfig/network-scripts/ifup-eth ifcfg-wlan0
 7893 ?        S<     0:00          \_ /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-wlan0.leases -pf /var/run/dhclient-wlan0.pid wlan0

The only udev rule that mentions udev is the persistent naming rule that anaconda added:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

As far as I can tell, this shouldn't happen; udev should not be attempting to bring up wlan0 on suspend from resume...

Comment 1 Harald Hoyer 2009-05-25 08:41:39 UTC
anything in /lib/udev/rules.d which could trigger that?

Comment 2 James Ralston 2009-05-26 15:18:06 UTC
/lib/udev/rules.d/60-net.rules (from initscripts-8.95-1) contains:

ACTION=="add", SUBSYSTEM=="net", DEVPATH=="/devices/virtual/net/lo", RUN+="/sbin/ifup $env{INTERFACE}"
ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device", RESULT=="?*", ENV{INTERFACE_NAME}="$result"
SUBSYSTEM=="net", RUN+="/etc/sysconfig/network-scripts/net.hotplug"

...but I don't see how that would bring up wlan0.

Since from your response this doesn't seem to be a known issue, I'll put udevd in debug mode, slog through the suspend/resume output, and see if I can figure out what rule (or combination of rules) is causing this...

Comment 3 Harald Hoyer 2009-05-26 15:49:00 UTC
/etc/sysconfig/network-scripts/net.hotplug would, if the interface is deregistered and regestired again after resume.

do you have scripts installed which remove the wireless drivers before suspend?

Comment 4 James Ralston 2009-05-26 16:27:23 UTC
Ah, that's it, then:

$ cat /etc/pm/config.d/unload_modules
# 
# $ date; ./quirk-checker.sh 
# 
# Wed May 21 10:55:50 EDT 2008
# 
# Checking your system...
# 
# WARNING: iwl3945 is usually okay for suspend - but it might be worth trying
# unloading it.
# 
# WARNING: KVM will not suspend in kernels less than 2.6.23, but should work
# okay in later kernels.
# 
# Suggestions:
# 
# Add 'SUSPEND_MODULES="kvm_intel kvm iwl3945"' to
# /etc/pm/config.d/unload_modules!
# 

SUSPEND_MODULES="iwl3945"

Now, I could see if the iwl3945 driver behaves properly if I leave it loaded across suspend/resumes.

But what if it doesn't?  In the general case, how do we solve the problem of a driver that needs to be unloaded before suspending, but one whose corresponding device shouldn't be activated when the driver is loaded after resume?

Comment 5 Bill Nottingham 2009-05-26 16:35:35 UTC
Add 'HOTPLUG=no' to the ifcfg file.

In any case, closing this as the init scripts are behaving correctly.