Regarding compiling BIND 9.10.3-p4 on a SystemD Distro

[Anand Buddhdev]

On 23/03/16 14:51, Tony Finch wrote:

>> With systemd the methodology isn't that BIND notifies other things that
>> it is up.  It is that other things, if dependent upon BIND, have in
>> their systemd files a requirement that BIND be up before they start.
> 
> Yes, but how does systemd know when BIND is up?
> 
> (The Red Hat and five-ten-sg RPMs don't seem to have an answer.)

Systemd doesn't have any facility to run a script or check after
starting a daemon. If it did (like upstart's post-start stanza), then
you could just run "dig @localhost" in a loop and exit when it succeeds.
Upstart will not emit a "started named" event until the post-start has
completed. This allows other upstart jobs to wait on a "started named"
event before doing their thing.

However, Systemd has support for notifications via dbus. If named is
compiled with support for systemd, then named can send a notification
via dbus after it has started up. Other systemd units that need named to
be up can wait for this notification before starting.

The BIND systemd unit file could contain:

Type=dbus
BusName=named
ExecStart=/usr/sbin/named -f

Now, the named process is expected to acquire the name "named" on the
bus. Any unit that has "Requires=named" or "After=named" will wait until
the name on the bus is acquired.

Knot DNS, for example, has a compile-time option to link against systemd
libraries. Then, when Knot starts, it loads all its zones in, does
whatever else it needs to do, and then sends a notification via dbus.

If anyone cares about this, they could open a feature request to add
Systemd dbus notification support to BIND. Good luck with it :)

Regards,
Anand