RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1129924 - Can not kill the dhclient process when repeatedly load/unload nic driver under ipv6 environment
Summary: Can not kill the dhclient process when repeatedly load/unload nic driver unde...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Amos Kong
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-14 02:04 UTC by Qian Guo
Modified: 2015-05-04 02:31 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-04 02:31:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Patch to ifup/ifdown to track who launched it (559 bytes, text/plain)
2015-04-09 17:36 UTC, Vlad Yasevich 		no flags Details
View All

Description Qian Guo 2014-08-14 02:04:16 UTC 
Description of problem:
After guest repeatedly load/unload nic driver,  there's a dhclient process in guest, and if kill it, will then automatically start another, and this cause guest can not get the ipv6 global address from a dhcp6 server

Version-Release number of selected component (if applicable):
kernel-2.6.32-496.el6.x86_64
qemu-kvm-0.12.1.2-2.434.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Guest/hosts are in ipv6 environment, they get ipv6 global addresses via dhcp server of a router

2.Boot guest, it can get the ipv6 global address
# /usr/libexec/qemu-kvm -cpu Penryn -m 4G -smp 4 -M pc -enable-kvm -name rhel6 -nodefaults -nodefconfig -vga std -monitor stdio -drive file=/mnt/rhel66basecp1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,werror=stop,rerror=stop,aio=native,cache=none -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 -spice disable-ticketing,port=5900 -vga qxl -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-netpci0,mac=54:52:01:21:1a:01

3.Inside guest, load/unload nic driver repeatedly
# while true ; do modprobe -r virtio-net ; sleep 0.1 ; modprobe virtio-net ; sleep 0.1 ; ifconfig eth0 up ; done

4.Quit the script, and then up the eth0


Actual results:
eth0 can get ipv6 address, but after a while lost it, I checked in the system, there's a dhclient process, which if kill it, will quickly start another. 

# ps aux |grep dhclient
root     13255  0.0  0.0   9120  1596 ?        S<   22:00   0:00 /sbin/dhclient -1 -q -cf /etc/dhcp/dhclient-eth0.conf -lf /var/lib/dhclient/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid eth0
root     13321  0.0  0.0 103252   864 pts/1    S+   22:01   0:00 grep dhclient


Expected results:
the process can be killed successfully, and do not resume back.

Additional info:
Test with e1000 nic, hit same issue
Comment 1 Qian Guo 2014-08-14 02:09:50 UTC 
If configure ipv4 static address to the nic, after a while, this address will disapear.


I have disabled and stopped NetworkManger service.
Comment 4 Amos Kong 2015-03-24 18:42:19 UTC 
Nic driver will request address from dhcp server by dhclient process after each init/loading. If dhclient will be started automatically in step 3 (because you wrote 'when' not 'after'), it's not a Bug. However it's not a common use case.
Comment 5 Qian Guo 2015-03-25 05:03:59 UTC 
(In reply to Amos Kong from comment #4)
> Nic driver will request address from dhcp server by dhclient process after
> each init/loading. If dhclient will be started automatically in step 3
> (because you wrote 'when' not 'after'), it's not a Bug. However it's not a
> common use case.

Hi, Akong

In comment 0, and for step 3, it was just load/unload the driver, and at this time, I did not check the dhclient process status,I think no need to check since the nic is in fast init/loading.

And in step4, I quit the script, meant that the nic had stopped the init/loading, it is already inited, and after this step, the nic can get the address first, but since the dhclient process can not be killed or dispeared itself, the nic can not remain the ip address.


What do you mean "when" or "after" ?

I will reopen it, since if repeatedly load/unload the driver, we can not use ipv6 address, and it is the issue.
Comment 6 Vlad Yasevich 2015-03-25 14:24:19 UTC 
This bug reminds me of some of the issues I've seen a while ago doing the same thing.  From what I remember, the issue then was the udev would queue up events
as the devices appear and disappear.  If you do it fast enough, then you might
get into a situation where you've just kicked off dhcp on the device that you
are now removing.  In this case, dhcp client gets stuck waiting for device and
after this, the udev events start piling up.  Once you stop fooling with
devices and kill dhcp, that gets udev unstuck and you you start handling all
the events again.  So, if you manually assign an address, dhcp client will remove it.

You could add some debug output to /sbin/ifup and /sbin/ifdown to see how/when
udev uses it.

-vlad
Comment 7 Qian Guo 2015-03-30 01:28:39 UTC 
(In reply to Vlad Yasevich from comment #6)
> This bug reminds me of some of the issues I've seen a while ago doing the
> same thing.  From what I remember, the issue then was the udev would queue
> up events
> as the devices appear and disappear.  If you do it fast enough, then you
> might
> get into a situation where you've just kicked off dhcp on the device that you
> are now removing.  In this case, dhcp client gets stuck waiting for device
> and
> after this, the udev events start piling up.  Once you stop fooling with
> devices and kill dhcp, that gets udev unstuck and you you start handling all
> the events again.  So, if you manually assign an address, dhcp client will
> remove it.
> 
> You could add some debug output to /sbin/ifup and /sbin/ifdown to see
> how/when
> udev uses it.
> 
> -vlad

Hi, Vlad

How should I do to get the debug logs for you, could you provide the method?

thanks
Comment 8 Vlad Yasevich 2015-04-09 17:36:31 UTC 
Created attachment 1012765 [details]
Patch to ifup/ifdown to track who launched it

Try the attachment patch.  It will report the device that is being brought up/down and the pids for if* and the parent.  Might help you track things.
Comment 9 Amos Kong 2015-05-04 02:31:49 UTC 
Not a common usecase, not from customer, close as WONTFIX.
Note You need to log in before you can comment on or make changes to this bug.