dhcpcd not killed

DJ Lucas dj at linuxfromscratch.org
Fri Aug 17 23:08:20 PDT 2007


David Olsson wrote:
> This got lost, I think.  So here it is again.
>
> On my BLFS 6.2 system, the SysVinit script
>
>     /etc/rc.d/init.d/network stop
>
> does not kill dhcpcd.  Tracing it to the script
>
>     /etc/sysconfig/network-devices/services/dhcpcd
>
> it turns out that if the dhcp lease time is infinite, the script believes that dhcpcd exited after startup.  Such is not the case, and I don't see in the dhcpcd docs that it should be true.  Is anyone familiar with these scripts?  The question is, shall we eliminate the check for infinite lease time, and kill the running dhcpcd.
>
>   
No...have to account for multiple interfaces.  Also, this was the case,
it did exit at one time...I verified that it worked when the change was
made to the scripts...I almost always use RL1 to test service scripts.
> Why hasn't anyone noticed this, you ask?  Because shutdown sends dhcpcd a terminate signal and dhcpcd is well-behaved, that being what it expects.  However, if you
>
>     telinit 1
>
> then
>
>     telinit 3
>
> you get a nasty error message that interrupts the SysVinit sequence and tells you you'd better track down the problem and report it.  So I did.
>   
If the interface was downed correctly, then there should be no address
assignment, doesn't matter if dhcpcd is already running.  Seems like
something might have been broken in newer dhcpcd.  Quick thought, does
the lease info file still exist in RL1?  If the lease info file is
removed, does it then work correctly jumping back into 3?
> Additional Point:  If the scripts DO kill dhcpcd, they do it with
>
>     dhcpcd -k
>
> which does NOT seem to be the recommended way to stop dhcpcd.  With '-k' dhcpcd destroys the ip info cache, so that next time it will request a new ip address, rather than first trying to reestablish the old one.  dhcpcd EXPECTS to receive a terminate (SIGTERM) signal, in which case the cache is preserved.  It looks to me like if we do not set DHCP_STOP in
>   
Bad assumption.   SIGHUP, or the -k switch, *is* the preferred way to
terminate a lease provided by dhcpcd for the majority of users (LANs). 
The current manpage doesn't mention it, but IIRC, with the -k switch you
can release by interface.  When using -k (or if SIGHUP is received),
then a DHCP_RELEASE is sent to the DHCP server, as should almost always
be done unless you don't want the server to know you've gone.   I'd much
rather get a resolution failure right off the bat than to wait for a
connection attempt to time out.

The exception is usually cable modem users.  IME, cable companies don't
like to give static addresses on consumer packages...or if they do offer
you one, it's be almost as cheap to get 5 addys in the business class
package.  But in most scenarios, it's the server's job to assign an
address, not the client's job to make a suggestion to the server.

I should also put out the disclaimer:  This is the way dhcpcd *used* to
behave...I haven't used it in a long time.  I think it was me that added
the check for the infinate lease after a bug report was submitted, but I
can't remember how long ago, or how many versions ago that was...Hell,
I'm not even positive that I made the change, but I do remember the
conversations about it.


-- DJ Lucas




More information about the blfs-dev mailing list