will dynamic dhcpd.conf be supported in future releases

jw354 jw354 at cornell.edu
Fri Aug 11 01:29:56 UTC 2006


On Aug 10, 2006, at 8:06 PM, Ted Lemon wrote:

> On Aug 10, 2006, at 4:02 PM, ashok singh wrote:
>> stopping and starting takes more time than just handling the SIGHUP
>> for dynamic dhcpd.conf. The overall response time in both the cases
>> is my concern.
>
> This is actually not true, unless you have a really slow dynamic
> linker.   Deallocating memory is not free - it costs CPU time, cache
> misses and page faults.   Furthermore, you still have to do all the
> work of re-parsing and re-allocating memory for the config file.
> You really are better off just starting from scratch, unless, as I
> say, you have a really slow dynamic linker.   Since dhcpd depends on
> very few shared libraries, I sincerely doubt that this is an issue.
>
> I think you're imagining that the DHCP server could do some kind of
> incremental parse and thereby save time and prevent thrashing, but
> this isn't possible.   Or you may not realize that the server keeps
> the entire database and configuration in memory - it doesn't reread
> the configuration file every time a request comes in, as would, for
> example, a typical BOOTP server.
>

I've wondered why a daemon couldn't handle a HUP simply go through
its TERM processing, then exec'ing itself with the same parms it was
originally started with.  I can easily imagine there's more to it than 
that
to assure the new instance runs under a completely clean slate, but I
still like the idea.

What would this gain?  I have had the experience of writing a script
to stop and start dhcpd during production.  To assure the
processes didn't overlap (which for some daemons, can result  in
no pid file, among other things), I incorporated a loop that tests
to see that the old process has gone away.  Later I had to tune the
sleep-length in the loop so our process monitor wouldn't alert
us that there was no dhcpd process running.  I'd love to do away with 
all
that crap and have a clean way to start the new process immediately
after the old one stops.

John Wobus



More information about the dhcp-users mailing list