dhclient3 keeps running after ifdown

Bug #38140 reported by Tormod Volden on 2006-04-05
72
This bug affects 7 people
Affects Status Importance Assigned to Milestone
dhcp3 (Ubuntu)
Medium
Unassigned

Bug Description

After booting, eth0 is up and dhclient3 is running. However, eth0 still doesn't have an address, see bug #33968, so I have to do an ifdown and ifup to make things work.

I have noticed that after running ifdown, the dhclient3 process is still running. If I just run ifup afterwards, there will be two of them running.

(ifupdown 0.6.7ubuntu7 and dhcp3-client 3.0.3-6ubuntu6)

$ ps ax|grep dhc
 3387 ? S< 0:00 dhclient3 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0

Update: Please note that this also affects the init.d/networking script.

Before running ifdown, can you do:

  ps ax | grep dhc
  var /var/run/dhclient.eth0.pid

Then do "ifdown eth0" and repeat the two commands.

Changed in ifupdown:
assignee: nobody → keybuk
status: Unconfirmed → Needs Info

The pid file is empty before and after. Only the timestamp of the file changes. See session output.

(The timestamp before is two hours in the future because the hwclock is running localtime.)

Tormod Volden (tormodvolden) wrote :

Could there be a relation to bug #33968 "Re: dhclient fails when not using UTC in hwclock" ?

dhclient's pid file shouldn't be empty

Changed in ifupdown:
assignee: keybuk → pitti
tho (tho) wrote :

Bug 49801 has been marked as duplicate of this bug, hence I add the comment here:
49801 might actually be caused by the (erroneous) assumption of the if-up/down tools that their configuration file is immutable. If, e.g. the configuration file is adjusted to use static address assignement, after an IP address was allocated using DHCP during if-up, but before if-down is executed, the latter wont attempt to kill the dhcp client.

John Clarke (jrc61) wrote :

I'm also adding this comment because bug 49801 has been marked as a duplicate of this one. I'm not sure they are the same: the problem, dhclient not killed, is the same, but the conditions are different.

I installed Edgy on a new machine late yesterday, changed eth0 from dhcp to static in /etc/network/interfaces, ran ifdown eth0 && ifup eth0 and verified that eth0 had come back up with the correct static address.

All was well went I went home a few hours later but when I came back this morning discovered that the address assigned to eth0 had changed because the dhcp client was still running.

/var/run/dhclient.eth0.pid was not empty; it contained the pid of the rogue dhclient process.

I'll second tho's suggestion: could it be caused by ifdown assuming that the relevant part of /etc/network/interfaces hasn't changed since the network was brought up?

MrZaius (cragos) wrote :

With a new, updated Edgy install, I took the default /etc/network/interfaces and replaced it with the following:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.5.2
    netmask 255.255.255.0
    gateway 192.168.5.1

After doing so, I ran;
/etc/init.d/networking restart

However, 30 minutes later, my system was unreachable at that IP, having received a DHCP lease. Found that the dhclient3 process was still running after the restart.

As ubuntu's networking init script is little more than a front-end to ifup/ifdown, it becomes prone to bug 38410.

description: updated
armatus (armatus) wrote :

i have the same bug!
how can i disable dhclient and use onle my static ip in /etc/network/interfaces?

Changed in dhcp3:
status: Needs Info → Confirmed
jordg (gbj) wrote :

I have the same issue with usb0 and bnep0
Has anyone been able to track down the cause of this?

jordg (gbj) wrote :

One thing I noticed is that dhclient3 releases the lease before it shuts down. Man dhclient3 look for -r option
It seems that dhclient3 will not exit if it cannot release the lease.
Is this the case?

jordg (gbj) wrote :
Download full text (9.2 KiB)

I have been trying to get this working for some time. I can offer some observations but no answers.

1, This is the same symptom with USB and Bluetooth and other devices.
2, On first insertion of USB cable network comes up OK. Looking at /var/log/syslog

Jul 25 13:23:43 bwing kernel: [326431.367963] usb 1-1: new full speed USB device using ohci_hcd and address 86
Jul 25 13:23:43 bwing kernel: [326431.465212] usb 1-1: configuration #1 chosen from 1 choice
Jul 25 13:23:43 bwing kernel: [326431.477055] usb0: register 'cdc_subset' at usb-0000:00:02.0-1, Linux Device, 36:ea:bb:7e:ac:8c
Jul 25 13:23:43 bwing NetworkManager: <debug info>^I[1185333823.529149] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_49f_505a_noserial').
Jul 25 13:23:43 bwing NetworkManager: <debug info>^I[1185333823.635551] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial').
Jul 25 13:23:43 bwing NetworkManager: <debug info>^I[1185333823.683519] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/net_36_ea_bb_7e_ac_8c').
Jul 25 13:23:43 bwing NetworkManager: <debug info>^I[1185333823.735785] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_49f_505a_noserial_usbraw').
Jul 25 13:23:45 bwing avahi-daemon[4925]: Registering new address record for fe80::34ea:bbff:fe7e:ac8c on usb0.*.
Jul 25 13:23:47 bwing avahi-daemon[4925]: Joining mDNS multicast group on interface usb0.IPv4 with address 192.168.211.2.
Jul 25 13:23:47 bwing avahi-daemon[4925]: New relevant interface usb0.IPv4 for mDNS.
Jul 25 13:23:47 bwing avahi-daemon[4925]: Registering new address record for 192.168.211.2 on usb0.IPv4.
Jul 25 13:23:53 bwing kernel: [326436.318568] usb0: no IPv6 routers present

3, Removal USB cable leaves an entry for usb0=usb0 in /var/run/network/ifstate dhclient is still running
    1097 ? S<s 0:00 dhclient3 -pf /var/run/dhclient.usb0.pid -lf /var/lib/dhcp3/dhclient.usb0.leases usb0
4, Insertion of USB Cable /var/log/syslog seems avahi-daemon misses out

Jul 25 13:28:32 bwing kernel: [326564.547139] usb 1-1: new full speed USB device using ohci_hcd and address 87
Jul 25 13:28:33 bwing kernel: [326564.651096] usb 1-1: configuration #1 chosen from 1 choice
Jul 25 13:28:33 bwing NetworkManager: <debug info>^I[1185334113.086586] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_49f_505a_noserial').
Jul 25 13:28:33 bwing kernel: [326564.662938] usb0: register 'cdc_subset' at usb-0000:00:02.0-1, Linux Device, 36:ea:bb:7e:ac:8c
Jul 25 13:28:33 bwing NetworkManager: <debug info>^I[1185334113.210916] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial').
Jul 25 13:28:33 bwing NetworkManager: <debug info>^I[1185334113.269558] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/net_36_ea_bb_7e_ac_8c').
Jul 25 13:28:33 bwing NetworkManager: <debug info>^I[1185334113.286177] nm_hal_device_added (): New device added (hal udi is '/org/freedesktop/Hal/devices/usb...

Read more...

bamyasi (iadzhubey) wrote :

Same bug here, running Ubuntu Server 7.04 with latest updates installed. After reconfiguring eth0 from dynamic to static and performing ifdown eth0/ifup eth0 dhclient3 is still running and keeps mangling interface address later on. I also notice the following error message in /var/log/daemons.log

Sep 8 20:18:43 xxxxx dhclient: can't create /var/lib/dhcp3/dhclient.eth0.leases: Permission denied

and this is indeed impossible since dhclient3 runs under dhcp user while:

ls -lh /var/lib/dhcp3/
total 0
-rw-r--r-- 1 root root 0 2007-09-09 16:08 dhclient.eth0.leases

(unless of course dhclient3 can somehow elevate its state back to root for performing operations on the lease files)

I am surprised this bug has not been fixed yet after many months. I am also surprised it is marked as of Medium importance. I believe it is a blocker.

Martin Pitt (pitti) on 2008-03-19
Changed in dhcp3:
assignee: pitti → nobody
Dana_r (danarea) wrote :

For anyone experiencing this issue, a work around is to perform kill -1 on dhclient (prevents a new ip from being obtained). I performed a system restart after doing this and dhclient did not start again, and the correct static IP was set.

jordg (gbj) wrote :

Found this at: http://wiki.openmoko.org/wiki/USB_Networking#Ubuntu_.28Tested_with_Feisty.2C_Gutsy_and_Hardy.29

It seems that LABEL="net_end" is in the wrong place
Can this be fixed now?

Edit /etc/udev/rules.d/85-ifupdown.rules

SUBSYSTEM=="net", DRIVERS=="?*", GOTO="net_start"
GOTO="net_end"

LABEL="net_start"

# Bring devices up and down only if they're marked auto.
# Use start-stop-daemon so we don't wait on dhcp
ACTION=="add", RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}"

LABEL="net_end"

ACTION=="remove", RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}"

Tormod Volden (tormodvolden) wrote :

jordg, the net_end label is in the right place on Hardy. Note that the labels net_start and net_end are used in place of a if-then structure. This is because udev rules can not use if-then clauses so one has to resort to good old spaghetti programming. If the subsystem is not "net" the whole script should be skipped. On the "add" action ifup is run, on "remove" ifdown is run.

Adi Yesaya (adiyesaya) wrote :

Hi,

Is there an update / bug fix for this issue? I've been dealing with the same problem and it frustrates me to see my fixed ip at my interface changes every couple minutes.

Thanks for any hints/help.

Kendall Gifford (zettabyte) wrote :

Still present in 11.10 server too.

Brijam (brian-opensourcery) wrote :

I'm experiencing this on 11.10 as well. So... any chance we can get this resolved? It's a really irritating bug that's confirmed and been around for six years. Anything I can do to help?

Kieran Levin (kieran-levin) wrote :

This is still present on ubuntu server 12.04 - i am guessing it is from upstream debian?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers