Red Hat Bugzilla – Bug 177795
nics automatically activated after unclean shutdown
Last modified: 2014-03-16 22:57:39 EDT
Description of problem: After unclean shutdown, nics automatically activated even though nic interfaces have onboot=no set. 'service network restart' correctly deactivates/activates the respective nics. a manual reboot on the prompt also shows the correct behavior. Version-Release number of selected component (if applicable): How reproducible: all the time Steps to Reproduce: 1. have multiple nics in system and configure some ifcfg files to have onboot=no 2. perform unclean shutdown by removing power cable from system 3. boot system back up Actual results: all nics activated Expected results: nics with onboot=no should not be active Additional info:
What version of initscripts?
initscripts-7.93.20.EL-1
Also, what version of hotplug?
hotplug-2004_04_01-7.6
Hm, odd. This seems like a rehash of 157252 and 153669, which are fixed in those versions. What do your ifcfg files look like?
i actually experienced bug 153669 because I had El4 U1 installed at the time. Then I installed El4 U2 and saw that the manual reboot works correctly. However, when the system goes down uncleanly, the onboot=no is still not honored when system comes back up. ifcfg-eth0 ========== DEVICE=eth0 BOOTPROTO=none HWADDR=00:08:79:08:ED:6A ONBOOT=no TYPE=Ethernet BROADCAST=192.168.200.255 IPADDR=192.168.200.171 NETMASK=255.255.255.0 ifcfg-eth2 ========== DEVICE=eth2 BOOTPROTO=none HWADDR=AA:30:78:32:7E:1B IPADDR=192.168.13.171 NETMASK=255.255.255.0 ONBOOT=yes TYPE=Ethernet I expect eth0 to not activate during boot.
Does /var/lock/subsys/network exist on these unclean boots?
yes
OK, so the hotplug script sees that that exists, and therefore assumes the network is up and tries to bring up the interface. Of course, this all before the root FS is read/write, so we can't remove the lock file.
You're right. I removed the lock file and did an unclean reboot. The respective interfaces are brought up/down correctly. Any idea when this might get fixed?
Have to find a clean way to fix it.
Created attachment 123350 [details] make sure we're in a numeric runlevel before running ifup Does the attached patch fix it for you?
patch doesn't work. I added debug messages to net.agent and found that runlevel was already set to 3 before the runlevel comparison
Hm, if it happens because /var/lock/subsys/network is there, that means it's in rc.sysinit. The runlevel should *not* be returning 3 there... except that the old /var/run/utmp is there from the previous boot, and runlevel is reading that. Back to the drawing board.
shouldn't the runlevel be cleared or reset at boot time seems like we're uncovering problems of much wider scope any service/operation that does a file lookup might get out of sync from an unclean reboot depending on service/operation sequence
(In reply to comment #15) > shouldn't the runlevel be cleared or reset at boot time Sure, later in rc.sysinit. The hotplug events happen before that, before the filesystem is even mounted read-write. > any service/operation that does a file lookup might get out of sync from an > unclean reboot depending on service/operation sequence Nah, most everything else happens after rc.sysinit ends.
Created attachment 124289 [details] dirty hack: check for rc.sysinit Does this work better? It's a gross hack...
yes, it works. can you formally release this fix?
Oops, sorry about that. Moving this to where it's being tracked for a RHEL update. *** This bug has been marked as a duplicate of 183706 ***