"already exists" logging question

[Cathy Almond]

On 14/03/12 11:41, Edward DeLargy wrote:
> I could be wrong but I would think that if the log is stating that the
> entry already exsists you would need to clear any dhclient data associated
> with that entry. You may want to try running the tail as you restart the
> service to see if it will point to the specific issue. If a dhclient entry
> is there it will tell you the exact problem. Also, on the number of logs.
> They would grow as dhclient requests increase. you may want to look at the
> TTL in your conf file to see if the TTL is so low that the renewals are
> filling your logs up. Hope this helps. If not let me know what you found is
> the issue.
> 
> 
> On Tue, Mar 13, 2012 at 1:46 PM, Raymond Drew Walker <Ray.Walker at nau.edu>wrote:
> 
>> Anyone care to chime in on this?
>>
>> Raymond Walker
>> Software Systems Engineer Sr.
>> ITS Northern Arizona University
>>
>>
>> -----Original Message-----
>> From: Raymond Walker <Ray.Walker at nau.edu>
>> Reply-To: Users of ISC DHCP <dhcp-users at lists.isc.org>
>> Date: Thu, 1 Mar 2012 22:59:12 +0000
>> To: "dhcp-users at lists.isc.org" <dhcp-users at lists.isc.org>
>> Subject: "already exists" logging question
>>
>>> After upgrading from 3.0.x to 4.2.x we have been noticing logs like such
>>> when restarting the DHCP service:
>>>
>>> 03/01/2012 15:09:41 /usr/local/opt/dhcpd/dhcp.leases line 792: host
>>> student24453.student.nau.edu-dynamic: already exists
>>> 03/01/2012 15:09:41 }
>>> 03/01/2012 15:09:41  ^
>>>
>>>
>>> While the client seems to be recieving a proper IP and functioning as
>>> expected, I could not find any information on this log. It seems that the
>>> number of these logs grow as DHCP traffic increases, which is our current
>>> concern.
>>>
>>> When examining the dhcp.leases and dhcp.leases~ files, all associated
>>> entries including reverse lookup seem to be correct and no duplicates (to
>>> my knowledge) are found. I could provide specific information if
>>> requested.
>>>
>>> Could someone explain why this happens, and suggested methods to eliminate
>>> it if necessary?

I was curious about this myself and discussed it with one of our engineers.

We think the error's most likely being generated from parsing a host
statement - usually found in the config file rather than the leases
file, but those created via OMAPI go in the leases file.

Does this give you something else to look for in your investigations?

Cathy