Description of problem:
I have modified my eth0 interface configuration using the NetworkManager GUI utility. It created a /etc/sysconfig/network-scripts/ifcfg-Auth_eth0 script with content as follows:
(I added the DHCP_HOSTNAME entry by hand). Now when I reboot my system, dhclient is being run TWICE. To debug this I renamed dhclient and replaced it with a script that generated some debugging then invoked the real dhclient. I can see that the first time dhclient is invoked it's run by the S10network script and the second time it's run by NetworkManager.
The result of this is that my system obtains two leases: one lease is kept in /var/lib/dhclient/dhclient-eth0.lease (the one obtained when S10network runs it) and the other is kept in /var/lib/dhclient/dhclient-$UUID-eth0.leases where $UUID is the value set in the ifcfg-Auto_eth0 above.
This would be only an annoyance except for one thing: the two different leases have DIFFERENT IP ADDRESSES. Sometimes it works out and the IP address associated with the hostname (via DHCP_HOSTNAME) in DNS is the same as the one configured on the local interface, but sometimes it doesn't work out and the hostname and IP address are different... then I can't access the system. I suppose there's some sort of timing issue with the DHCP handshake.
The question is why is the same interface trying to obtain a lease twice and how can I keep that from happening? It seems that SysV network and NetworkManager are not in agreement over who controls the interface and both are trying to control it.
This is happening across all of my RHEL 6.2 installs and causing instability.
Version-Release number of selected component (if applicable):
$ rpm -qf /etc/rc.d/init.d/network
$ rpm -qf /usr/sbin/NetworkManager
$ rpm -qf /sbin/dhclient
Steps to Reproduce:
1. Configure an interface using NetworkManager
3. Verify that dhclient was run twice by looking for duplicate leases files in /var/lib/dhclient
dhclient run twice for the interface
dhclient only run one time and a single lease obtained
See 817660, sorry about the duplicate.
This also seems to be related to bug #607921. Although that bug is related to iSCSI but the underlying issue is the same one as in this bug.
However, apparently (according to the comments) there's a workaround for iSCSI, but that workaround does not work for my situation.
That bug has been open for almost two years; is there any way to get some progress on this problem? It's biting us hard in our Red Hat EL 6.2.2 Workstation deployments here and I don't see an obvious workaround.
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
How many ifcfg files do you have in /etc/sysconfig/network, and what are their names?
I meant /etc/sysconfig/network-scripts/ ...
Hi Dan. I have two: one for lo and one created by NetworkManager:
~$ ls -1 /etc/sysconfig/network-scripts/ifcfg-*
Here's what I think is going on.
If you have a standard desktop install, then both sysv networking (/etc/init.d/network) and NetworkManager are "enabled".
The sysv networking looks for files in /etc/sysconfig/network-scripts and brings up interfaces there as appropriate. However it appears that a normal desktop install does not, by default create any files in /etc/sysconfig/network-scripts (at least when I installed a new RedHat EL 6.3 yesterday, it didn't create any). So at first install, the sysv network scripts don't actually do anything. When I log in, NetworkManager brings up the interface using its default config (DHCP, etc.) without any files in /etc/sysconfig/network-scripts.
However, the minute you modify any of the interface configuration (set the DHCP client ID for example), then NetworkManager appears to create an /etc/sysconfig/network-scripts/ifcfg-Auto_eth0 (or whatever name you gave the interface in NetworkManager) and it puts a fully-formed sysv network script in there, plus the setting you modified (DHCP_CLIENT_ID).
Now the next time you reboot, the sysv network scripts see this ifcfg-Auto_eth0 file and they see that it's got BOOTPROTO=dhcp and ONBOOT=yes in it, and those scripts run the DHCP client and they get an IP address. Then later (I guess when you log in), NetworkManager ALSO sees that the interface is configured, without checking first to see if the interface is already up, it re-runs the DHCP client protocols.
This causes multiple problems: first, if you configure the sysv init dhclient scripts (/etc/dhcp/dhclient-hook or whatever) they will run at the first DHCP request is made but not the second (there's apparently no way to hook into NetworkManager for this, which is a bummer).
Second, in our environment (for some reason I don't understand, not having any access to the DHCP server logs etc.), these two requests return DIFFERENT IP addresses, even though they are both registering the same MAC address. Not only that but our DHCP server is keeping both lookups in the DNS server, so now two different IP addresses are resolving to the same hostname, which is very bad.
Anyway, there seems to be a confusion because sysv network and NetworkManager are sharing the same config files, but they are both trying to operate on them.
Unfortunately I need both: this is a desktop and I want my network to come up when the system boots, even if I'm not there to log in. And at the same time I want the NetworkManager icon on the desktop so I can manage the network using it (change parameters, start/stop VPN, etc.)
This as a duplicate of bug #607921
*** This bug has been marked as a duplicate of bug 607921 ***