If I remove a network device under control of dhclient (e.g. a wifi
adapter that supports being turned off by ACPI), dhclient will
complain but it will not die. As I move around a lot and turn wifi
on and off as needed, I end up with dozens of dhclient processes for
the wifi device, which tend to like to get into each others way.

I think it would make sense for dhclient to exit when its device
disappears.

lapse:/etc/ifplugd/action.d# dhclient wifi
Internet Systems Consortium DHCP Client V3.0.3
Copyright 2004-2005 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

Listening on LPF/wifi/00:14:a4:04:ea:dc
Sending on   LPF/wifi/00:14:a4:04:ea:dc
Sending on   Socket/fallback
DHCPDISCOVER on wifi to 255.255.255.255 port 67 interval 7
*** i turned the device off here ***
receive_packet failed on wifi: Network is down
DHCPDISCOVER on wifi to 255.255.255.255 port 67 interval 9
send_packet: No such device
DHCPDISCOVER on wifi to 255.255.255.255 port 67 interval 11
send_packet: No such device
DHCPDISCOVER on wifi to 255.255.255.255 port 67 interval 11
send_packet: No such device
DHCPDISCOVER on wifi to 255.255.255.255 port 67 interval 11
send_packet: No such device
DHCPDISCOVER on wifi to 255.255.255.255 port 67 interval 12
send_packet: No such device
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
lapse:/etc/ifplugd/action.d# ps aux | grep [d]hc
root     23599  0.0  0.0   2164   508 ?        Ss   11:31   0:00 dhclient wifi

Hi DHCP hackers.

I recently received this bug report, which I'm forwarding on for
discussion/consideration.

regards

Andrew

I consider this an architectural problem.  It's not proper for a daemon
that might listen to multiple interfaces to exit prematurely.
Particularly when the intended design of the product was to run at all
times, and suspend/resume when interfaces are removed and inserted in
the system.

As I said on the dhcp-client mailing list recently, architecturally we
want to move to a single-daemon-per-interface model, and from there it
makes a whole lot more sense to exit jsut as a sanity check if the
interface the daemon was targetted to goes away.

I'm not sure this will make it into 3.1, but it is on our list.

also sprach David W. Hankins <David_Hankins@isc.org> [2006.03.03.0050 +0100]:

True, but this is not how it's used in Debian.

As said, for Debian, it would make sense to treat it
single-daemon-per-interface already, IMHO.

Dear submitter,

as the package isc-dhcp has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1143544

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)