Re: PID file ... not readable (yet?)

[Russ Allbery]

Robbie Harwood  writes:

> 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?

No, the sd_notify call in libsystemd quietly does nothing, successfully,
if the system wasn't booted with systemd.

-- 
Russ Allbery (ea...@eyrie.org)  

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: PID file ... not readable (yet?)

[Robbie Harwood]

Russ Allbery  writes:

> Benjamin Kaduk  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:
>
> #ifdef HAVE_SD_NOTIFY
> # include 
> #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?

Thanks,
--Robbie


signature.asc
Description: PGP signature

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: PID file ... not readable (yet?)

[Jaap Winius]

Quoting Greg Hudson :

> On 11/05/2017 05:36 AM, Jaap Winius wrote:
>>systemd[1]: krb5-kdc.service: PID file /run/krb5-kdc.pid \
>>  not readable (yet?) after start: No such file or directory
>
> Does everything seem to work aside from this warning message being
> produced, or is there an accompanying problem?

The accompanying problem is that the OpenLDAP consumer backend  
database I'm using is not able to replicate with its provider due to a  
Kerberos authentication problem (IIRC it attempts to authenticate as  
localh...@example.com). I thought that there might be a small chance  
these issues are related.

And again, this problem affects Debian stretch, but not jessie, which  
also uses systemd.

Cheers,

Jaap


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: PID file ... not readable (yet?)

[Russ Allbery]

Benjamin Kaduk  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:

#ifdef HAVE_SD_NOTIFY
# include 
#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.

-- 
Russ Allbery (ea...@eyrie.org)  

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: PID file ... not readable (yet?)

[Benjamin Kaduk]

On Sun, Nov 05, 2017 at 09:57:30AM -0500, Greg Hudson wrote:
> On 11/05/2017 05:36 AM, Jaap Winius wrote:
> >systemd[1]: krb5-kdc.service: PID file /run/krb5-kdc.pid \
> >  not readable (yet?) after start: No such file or directory
> 
> Does everything seem to work aside from this warning message being
> produced, or is there an accompanying problem?
> 
> There can be a very brief window of time between krb5kdc exiting on
> startup and its child process writing the pid file.  That window is
> normal for traditional Unix daemon programs (because of the way the
> daemon() function works) and isn't a problem as long as nothing wants to
> restart the KDC service in the first second of its life.  But it might
> be enough for systemd to complain.

I'd also add that Jaap (and everyone) should feel free to file Debian
bugs for issues, especially with the systemd configuration, since that
comes from the Debian packaging and is not part of upstream.  (That said,
it's certainly not wrong to ask about it here.)

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.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: PID file ... not readable (yet?)

[Greg Hudson]

On 11/05/2017 05:36 AM, Jaap Winius wrote:
>systemd[1]: krb5-kdc.service: PID file /run/krb5-kdc.pid \
>  not readable (yet?) after start: No such file or directory

Does everything seem to work aside from this warning message being
produced, or is there an accompanying problem?

There can be a very brief window of time between krb5kdc exiting on
startup and its child process writing the pid file.  That window is
normal for traditional Unix daemon programs (because of the way the
daemon() function works) and isn't a problem as long as nothing wants to
restart the KDC service in the first second of its life.  But it might
be enough for systemd to complain.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

PID file ... not readable (yet?)

[Jaap Winius]

Hi folks,

My network uses KDCs with OpenLDAP backends that run on Debian wheezy.  
That's all been working fine for a long time now, but earlier this  
year I tried and failed to add a KDC with an OpenLDAP backend based on  
Debian stretch (it runs, but can't authenticate properly to the KDC  
master -- see thread "KDC 1.15 startup error: Invalid credentials -  
while initializing database" starting 13 April 2017). I then set up  
another KDC with an OpenLDAP backend based on Debian jessie and that  
worked. However, one thing I believe I failed to mention in those  
earlier posts was this startup error:

   systemd[1]: krb5-kdc.service: PID file /run/krb5-kdc.pid \
 not readable (yet?) after start: No such file or directory

Perhaps I didn't mention it because the PID file never fails to appear  
and always contains the correct PID, but apparently it does not appear  
quickly enough. Does anyone know how to prevent this error? It's not  
generated on the jessie system.

The krb5-kdc.service file for my stretch system is as follows:

   [Unit]
   Description=Kerberos 5 Key Distribution Center

   [Service]
   Type=forking
   PIDFile=/run/krb5-kdc.pid
   ExecReload=/bin/kill -HUP $MAINPID
   EnvironmentFile=-/etc/default/krb5-kdc
   ExecStart=/usr/sbin/krb5kdc -P /run/krb5-kdc.pid $DAEMON_ARGS
   InaccessibleDirectories=-/etc/ssh -/etc/ssl/private  /root
   ReadOnlyDirectories=/
   ReadWriteDirectories=-/var/tmp /tmp /var/lib/krb5kdc -/var/run /run  
/var/log/krb5
   CapabilityBoundingSet=CAP_NET_BIND_SERVICE

   [Install]
   WantedBy=multi-user.target

Just today I moved krb5-kdc.service from /lib/systemd/system/ to  
/etc/systemd/system/ after modifying it to add the log directory and  
ran a "systemctl daemon-reload". I even ensured that the PIDFILE  
setting in /etc/init.d/krb5-kdc points to the same name --  
/run/krb5-kdc.pid -- but the result remains the same (although I  
suspect that in this case /etc/init.d/krb5-kdc is ignored).

So, any idea how to prevent this PID file error?

Thanks,

Jaap


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos