X-RT-Original-Encoding: utf-8 References: <62bc80a3-0d2f-916c-2a66-22e2859060f0@illinois.edu> Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="utf-8" In-Reply-To: <62bc80a3-0d2f-916c-2a66-22e2859060f0@illinois.edu> X-RT-Interface: Web MIME-Version: 1.0 Message-ID: X-Mailer: MIME-tools 5.508 (Entity 5.508) RT-Send-CC: Content-Length: 2782 Hello David: Thank you for your suggestion and for the taking the time to provide the makings of patch. It seems like a reasonable request. We are working towards a feature release, 4.4.0, expected to ship sometime January '18. We'll take your suggestion under consideration for possible inclusion in that release. We are a small non-profit with finite resources and so we must choose carefully where to allot them. Should we decide to include your suggestion we'll update this ticket accordingly. Regards, Thomas Markwalder ISC Softwawre Engineering On Wed Aug 16 00:02:37 2017, dmrz@illinois.edu wrote: > 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. >