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 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
