DHCPD dying..

[Matthew Carpenter]

Kurt Wall wrote:

>On Wed, Dec 01, 2004 at 12:04:16AM +1100, James McDonald took 359 lines to write:
>  
>
>>Matthew Carpenter wrote:
>>
>>    
>>
>>>I have seen DHCPd die a couple times over the last week on a 
>>>customer's site.  The messages seen after rebooting the system (this 
>>>was their attempt to troubleshoot before calling me) are as follows.  
>>>The one that catches me off guard is at 7:59:21 (Not Authoritative?), 
>>>although that is not the last message before dying.  At the end it 
>>>looks like DHCPd restarted (although I'm not sure why) and perhaps 
>>>found another DHCP server on the network?  Or does that mean there is 
>>>another DHCP server running on that box?
>>>      
>>>
>
>[~330 lines snipped]
>
>  
>
>>Guessing here but check that a windows 200x server dhcp box isn't 
>>running. They have a feature called "Authorization" which means only the 
>>servers that you specifically configure to be DHCP boxes are allowed to 
>>serve DHCP requests. It could be an error message from the remote DHCP 
>>box...
>>    
>>
>
><grump>
>So you had to quote *all* 350-odd lines of log message to add *5* lines of
>text?
></grump>
>
>I was going to propose that there's another DHCP server running somewhere.
>
>Kurt
>  
>
Thanks.  I'm thinking that.  I noticed that the newer versions of dhcpd 
want to see the term "authoritative;" either in the subnet definition or 
as a global declaration.  authoritative is used to assist in n00bs 
bringing up a dhcp server and not knowing what they are doing.  If dhcpd 
sees another dhcp server on the wire it won't send out DHCPNAKs:

The DHCP server will normally assume that the configuration information 
about a given network segment is not known to be correct and is not 
authoritative. This is so that if a naive user installs a DHCP server 
not fully understanding how to configure it, it does not send spurious 
DHCPNAK messages to clients that have obtained addresses from a 
legitimate DHCP server on the network.

I'm not sure if that is what we saw or not.  Since "rcdhcpd status" 
returned a "dead" status we know the process died unexpectedly.  Thanks 
for the comment.
Sorry about the long log file, but I wanted to be sure I didn't skip 
something that might have been important.

Thx,
Matt

ps.  It's nice to know I'm not /dev/nulled by *everyone* :)