Bug 1129924
Summary: | Can not kill the dhclient process when repeatedly load/unload nic driver under ipv6 environment | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Qian Guo <qiguo> | ||||
Component: | qemu-kvm | Assignee: | Amos Kong <akong> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6.6 | CC: | ailan, akong, bsarathy, chayang, jasowang, juzhang, michen, mkenneth, mst, qiguo, qzhang, rbalakri, virt-maint, vyasevic | ||||
Target Milestone: | rc | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-05-04 02:31:49 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Qian Guo
2014-08-14 02:04:16 UTC
If configure ipv4 static address to the nic, after a while, this address will disapear. I have disabled and stopped NetworkManger service. 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. (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. 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 (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 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.
Not a common usecase, not from customer, close as WONTFIX. |