Report information
The Basics
Id:
20890
Status:
resolved
Estimated:
2 hours (120 minutes)
Left:
60 hours (3,600 minutes)
Priority:
Low/Low
Queue:

BugTracker
Version Fixed:
(no value)
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
4.4.0
Priority:
P2 Normal
Severity:
S2 Normal
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
DHCP Common
Area:
bug

Dates
Created:Tue, 12 Jan 2010 17:40:35 -0500
Updated:Tue, 12 Dec 2017 07:35:32 -0500
Closed:Wed, 21 Sep 2016 09:47:10 -0400



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Subject: Allow use of devpoll or epoll in isclib when used with DHCP
While modifying DHCP to use isclib for some socket support I observed problems when using devpoll or epoll.  In order to proceed with the DDNS project I simply disabled them when building the library for use with DHCP.  When we have more time we should find and fix the underlying issue.

On Thu Jun 04 14:05:00 2015, fdupont wrote: > I removed the first line of the bindconfig in > util/Makefile.bind.in (the line which disables kqueue, > epoll and devpoll, i.e., all select() alternatives) on > a Fedora 22 virtual machine. > > As I expected the dhcpd server uses now epoll_wait() > and I didn't see any difference with a regular master one > used as a DHCPv6 server. > > So I believe we can simply add a new option in > configure and the real work will be to pass system tests. > > Shawn, if you'd like I can steal the ticket and propose > a patch for configure.ac. There are two items to worry about 1) do the current machines continue to work properly in background? The original issue was that the servers work properly in foreground but consume all cpu when run as a daemon. 2) If the current machines work properly (without a change to our code) how far back does this extend and do we still want to support OSes older than that support? We should probably be fixing the underlying issue either through re-arranging the code to open the socket later or by changing the options we choose for the socket to make sure the socket is properly handled through the fork call.