User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 X-Spam-Bar: X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 priorityscore=0 malwarescore=0 suspectscore=4 phishscore=0 bulkscore=0 spamscore=0 clxscore=189 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708150392 From dmrz@illinois.edu Wed Aug 16 00:02:35 2017 X-Spam-Origsender: dmrz@illinois.edu X-CLX-Response: 1TFkXGxITEQpMehcaEQpZTRdkRURPEQpZSRcHGRpxGwYHHBp3BhgaGgYaBho GGxMGGnEaEBp3BhoGGgYaBhoGGgYacRoQGncGGhEKWV4XaGN5EQpJRhdfQ19JdVpYRU5fSV5DRU QRCkNOFx9vQ1JJb2VlGGlsR0R5fAdcfX55YERnfR0aH19oT2hmEQpYXBcfBBoEGxseBxxMThMYT htJBRsaBBsbGgQeEgQSHBAbHhofGhEKXlkXe1N+a3MRCk1cFxkSEQpMWhdoaU1raxEKQ1oXHB4E GBgEGx0dBBkfEQpCXhcbEQpCRRdoZ21nfQV6H21EBREKQk4XbxwZfxxfaEZcYRIRCkJMF21DRkN LT1hae3JMEQpCbBduG0ISYFx5bkQZZhEKQkAXa31LbXsTH00TQmERCkJYF2doZ0VEWWlCeU1kEQ pNXhcHGxEKWlgXGxEKcGgXZhwbHkZPWVh6GRwQBxkaEQpwaBdhBQFCXn9oR2ldZBAHGRoRCnBoF 29jXxpecHJZSUdsEAcZGhEKcGgXb0AeRxISa0BlfWQQBxkaEQpwaBdmXmEaZEdNThlmRhAHGRoR CnBsF256ck0fW1NmZEUaEAcZGhEKbX4XBxsRClhNF0sRIA== Return-Path: X-Clientproxiedby: uex133.ad.uillinois.edu (192.17.212.209) To cex139.ad.uillinois.edu (64.22.177.35) content-type: text/plain; charset="utf-8"; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org X-Originating-Ip: [64.22.180.153] Subject: control timing for rewriting dhcpd.leases To: dhcp-suggest@isc.org From: "David Zych" X-Original-To: dhcp-public@bugs.isc.org X-Spam-Score: 0 Content-Language: en-US X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 Message-ID: <62bc80a3-0d2f-916c-2a66-22e2859060f0@illinois.edu> X-RT-Incoming-Encryption: Not encrypted X-CLX-Shades: None Delivered-To: dhcp-public@bugs.isc.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id E316AD78AEB for ; Wed, 16 Aug 2017 00:02:34 +0000 (UTC) Received: from pps03.cites.illinois.edu (pps03.cites.illinois.edu [192.17.82.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9FAA534A7D3 for ; Wed, 16 Aug 2017 00:02:06 +0000 (UTC) Received: from cex139.ad.uillinois.edu (cex139.cites.illinois.edu [64.22.177.35]) by pps03.cites.illinois.edu (8.16.0.17/8.16.0.17) with ESMTPS id v7G01uA2018740 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 15 Aug 2017 19:02:04 -0500 Received: from [10.192.167.133] (64.22.180.153) by cex139.ad.uillinois.edu (64.22.177.35) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 15 Aug 2017 19:01:55 -0500 Date: Tue, 15 Aug 2017 19:01:56 -0500 X-RT-Original-Encoding: utf-8 X-RT-Interface: Email Content-Length: 2146 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