PID file ... not readable (yet?)

Robbie Harwood rharwood at
Mon Nov 6 12:41:05 EST 2017

Russ Allbery <eagle at> writes:

> Benjamin Kaduk <kaduk at> writes:
>> I suspect that we would be a little friendlier to systemd if we
>> passed -n to krb5kdc and adjusted the unit file accordingly.  There
>> would still be a race window between when systemd thinks krb5kdc is
>> started and ready to accept connections and when that is actually the
>> case, but in both cases that window is small, and we cannot eliminate
>> it entirely without patching the code to call systemd-specific
>> functions.
> For what it's worth, that's a pretty light burden.  It's just the
> following Autoconf probe:
> PKG_CHECK_EXISTS([libsystemd],
>     [PKG_CHECK_MODULES([SYSTEMD], [libsystemd])
>      AC_DEFINE([HAVE_SD_NOTIFY], 1, [Define if sd_notify is available.])])
> (does require the pkg-config Autoconf stuff as well), the following at
> the start of the daemon C file:
> # include <systemd/sd-daemon.h>
> #else
> # define sd_notify(u, s)  0
> #endif
> and then just the following call when the daemon has started up and is
> ready for connections:
>     sd_notify(true, "READY=1");
> or, to be more complete, something akin to:
>     status = sd_notify(true, "READY=1");
>     if (status < 0)
>         warn("cannot notify systemd of startup: %s", strerror(-status));
> Then you can be a native systemd daemon and systemd will know exactly
> when the KDC is ready to respond to connections, which will resolve
> various race conditions when some other system service depends on the
> KDC for startup.

Won't this produce something that requires systemd if systemd was
present during build, thereby preventing a maintainer from shipping both
a sysvinit script and a systemd unit file?  Or am I misunderstanding?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
Url :

More information about the Kerberos mailing list