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):
all the time
Steps to Reproduce:
1. have multiple nics in system and configure some ifcfg files to have
2. perform unclean shutdown by removing power cable from system
3. boot system back up
all nics activated
nics with onboot=no should not be active
What version of initscripts?
Also, what version of hotplug?
Hm, odd. This seems like a rehash of 157252 and 153669, which are fixed in those
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.
I expect eth0 to not activate during boot.
Does /var/lock/subsys/network exist on these unclean boots?
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
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 ***