ISC DHCP does not work with BIND 9.10

Tomas Hozza thozza at redhat.com
Thu Feb 19 17:17:13 UTC 2015


Thank you for your reply.

On 02/19/2015 06:01 PM, 神明達哉 wrote:
> At Thu, 19 Feb 2015 17:26:19 +0100,
> Tomas Hozza <thozza at redhat.com> wrote:
>
> > There's [1] a packaging policy on Fedora,
> > that packages can't be shipped with bundled libraries,
> > which is a case of BIND bundled in DHCP tarball.
> > We'd like to ship bind-9.10.2 & dhcp-4.3.2 with next Fedora release (22).
> > Problem is, that dhclient/dhcpd don't play well with bind-9.10.
> > Jiri Popelka (the DHCP maintainer in Fedora) did some investigation and
> > they can't be stopped (have to be 'kill -9'ed) and don't work at all when
> > running in background.
>
> First off, do you mean dhcp-4.3.2rc1?  (I can't find a final release
> version of 4.3.2 on the ISC ftp site).

I meant dhcp-4.3.2b1.

> Secondly: did you try to link libisc/libdns etc from bind-9.10.2 to
> dhcp-4.3.2(rc1) instead of the one included in the dhcp source
> directory?

We are linking DHCP against separate build of BIND 9.10.2. In other words
we don't use the bundled bind in DHCP sources.

> If so, unless something has substantially changed in the dhcp side,
> that wouldn't work in my experience for the following two reasons:
>
> 1. On Linux libisc would enable epoll by default.  dhcp doesn't work
>    well with it; you'll need a library built disabling the epoll
>    support.
> 2. You stack trace seems to suggest libisc is built with enabling
>    threads.  dhcp doesn't work well with it either.
>
> Also possibly related to the second point, see comments in lib/isc/task.c:
>
>  * For BIND9 internal applications:
>  * when built with threads we use multiple worker threads shared by the whole
>  * application.
>  * when built without threads we share a single global task manager and use
>  * an integrated event loop for socket, timer, and other generic task events.
>  * For generic library:
>  * we don't use either of them: an application can have multiple task managers
>  * whether or not it's threaded, and if the application is threaded each thread
>  * is expected to have a separate manager; no "worker threads" are shared by
>  * the application threads.
>
> dhcp is only expected to work with the "generic library" (and also
> disabling epoll), but this comment now seems to be obsolete as there's
> no "generic" (formerly called "export") version of the library.
> Assuming the issue with epoll is somehow resolved, I suspect we'd need
> some run-time mechanism to enable the "multiple task managers" mode
> (while still enabling threads).  As far as I know the current
> implementation doesn't allow it.
>
> --
> JINMEI, Tatuya


We have been linking DHCP against separately built BIND in the past and everything
worked for years. Only thing that changed is that we updated latest BIND
9.9 to latest 9.10.


Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com


More information about the bind-users mailing list