Red Hat Bugzilla – Bug 143940
"service network stop" does not stop all active interfaces
Last modified: 2014-03-16 22:51:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
"service network stop" stops only interfaces listed in
/etc/sysconfig/network-scripts/ifcfg*. Other active interfaces (in
particular VMWare's vmnet* interfaces) are not stopped.
This causes apm suspend to leave interfaces up across the suspension
(even with NET_RESTART="yes"), which can break some systems. In
particular, it causes shutdown/reboot to hang after suspend/resume
when running VMware.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. "service network start" (e.g., at boot). Start unconfigured
network interface (e.g., "service vmware start" with vmware networking
2. "service network stop".
3. "service network status"
Actual Results: Unconfigured active interfaces are still listed as
# service network status
lo eth0 eth1
Currently active devices:
Expected Results: No interfaces listed as active.
See the discussion at
for a history of this diagnosis.
Is there a good reason for "service network stop" to only pay
attention to configured interfaces? Or should stopping the network
really mean stopping *all* network devices?
Well, it would require adding random support for other network types
that may not even work to 'correctly' bring it down (who is to say
that if you run 'ip link set <whatever> down' that some daemon won't
bring it back up later)
Why does vmware need a separate initscript for its networking, out of
I wasn't sure how many different ways there might be to get interfaces
up and down, but it turns out that vmware is definitely not standard.
The virtual ethernet modules are inserted and removed by vmware's
initscript along with the VM monitor module. I don't know if this
could be handled using the usual network-scripts configs and
modprobe.conf, but the program that the initscript invokes to do the
insertion and deletion is a binary, not just a script.
I guess the sensible workaround is something for vmware in
Probably, yes. And don't forget ACPI. *ducks*
Closing this; without specific configuration to handle other device types, it's
not really practical.