Editing dhcpd.conf without corrupting leases

Chris Buxton cbuxton at menandmice.com
Mon Apr 13 17:28:42 UTC 2009

On Apr 13, 2009, at 10:12 AM, Mr. Jan Walter wrote:
> It's also not clear from one paragraph what you're really doing, so  
> don't get huffy when others' assumptions don't correspond to your  
> reality. Really - sorry for trying to help.

Sorry to break into your conversation here, but yes, it was clear.

> There isn't any locking done on the leases or conf file by dhcpd  
> itself. What's most likely happening (without me reading through all  
> that source) is that if your web app's write of the config file is  
> not complete, while your cron is sending the SIGHUP to dhcpd, some  
> internal check fails and the leases file is considered corrupt.

You've misread the original post yet again. The web app doesn't touch  
the .conf file, the cron job does. And then, when it's finished, it  
might restart dhcpd. This part is working fine.

The problem is the lease database. The OP thinks that perhaps dhcpd  
gets interrupted while writing out the lease database, thereby  
corrupting it. But since dhcpd doesn't lock the file in any way,  
there's no way to test for this.

Adding a test step (dhcpd -T -t) will probably help, but it still  
leaves a small window between that test and the subsequent SIGTERM.

Ideally, the OMAPI protocol would be extended to have a 'reload'  
command. Lacking that, I don't see a perfect solution to the problem.  
The best I can think of is:

until dhcpd -T -t ; do
   sleep 1
/etc/init.d/dhcpd stop
if ! dhcpd -T -t ; then
   rm /path/to/leases file
/etc/init.d/dhcpd start

Chris Buxton
Professional Services
Men & Mice

More information about the dhcp-users mailing list