Bug 502080 - udev attempts to ifup-eth wlan0 upon resume from suspend
udev attempts to ifup-eth wlan0 upon resume from suspend
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-05-21 15:00 EDT by James Ralston
Modified: 2014-03-16 23:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-26 12:35:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Ralston 2009-05-21 15:00:57 EDT
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-*

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 04:41:39 EDT
anything in /lib/udev/rules.d which could trigger that?
Comment 2 James Ralston 2009-05-26 11:18:06 EDT
/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 11:49:00 EDT
/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 12:27:23 EDT
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!


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 12:35:35 EDT
Add 'HOTPLUG=no' to the ifcfg file.

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

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