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