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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
