| Subject: | control timing for rewriting dhcpd.leases |
| To: | dhcp-suggest@isc.org |
| From: | "David Zych" <dmrz@illinois.edu> |
| Date: | Tue, 15 Aug 2017 19:01:56 -0500 |
Currently dhcpd (4.3.6) rewrites its lease file about once per hour, at
an arbitrary time which effectively depends on when the process was started.
While it's rewriting the lease file it can't process client requests,
and on a very busy server with a large lease file this can cause the
socket buffer Recv-Q for 67/udp to fill up (visible instantaneously with
`netstat -nl --udp`) resulting in excess client requests getting
silently dropped by the OS. Admittedly this usually doesn't cause much
harm since DHCP clients are good at retrying, but it would be nice to
have some control over when it happens, especially in the case of a
failover pair (to ensure that it won't happen on both peers at the same
time).
I don't have a patch for this because C is not my strong suit, but I
think it would be relatively straightforward to implement configuration
options like this:
lease-rewrite-period 3600;
lease-rewrite-offset 1020; # 17*60
to indicate that the lease file on this server should be rewritten at
approximately 17 minutes past the hour (or shortly thereafter).
Basically in server/db.c instead of checking for
if (count && cur_time - write_time > LEASE_REWRITE_PERIOD)
we would check for
if (count && cur_time > next_write_time)
and then set the time of our next write to the appropriate offset within
the next period:
next_write_time = cur_time - (cur_time % LEASE_REWRITE_PERIOD) +
LEASE_REWRITE_PERIOD + LEASE_REWRITE_OFFSET;
Note that this does not assume cur_time itself has the desired offset;
if we start at 6:05 then we'll still schedule the next rewrite for 7:17.
(aside: one might argue that it should be 6:17 instead, which could of
course be arranged by making the computation a bit more complicated. It
doesn't make any difference to me either way; I'm only concerned about
the steady state behavior.)
Thanks,
David
P.S. Optionally, if the offset option is not configured, we could set
next_write_time = cur_time + LEASE_REWRITE_PERIOD;
instead to mimic the status quo.
--
David Zych
Lead Network Service Engineer
University of Illinois Technology Services