Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind

[Michael Stapelberg-15]

Package: krb5-kdc
Version: 1.7dfsg~beta3-1
Severity: normal

krb5kdc and kadmind are running, but there is no corresponding pidfile in
/var/run. Thus I cannot use a program like monit to monitor these processes.
Please let start-stop-daemon create a pidfile for both daemons.

Best regards,
Michael



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sam Hartman-3]

I don't think start-stop-daemon  can create the pid file because these process fork and daemon themselves.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Stapelberg-15]

Hi,

Excerpts from Sam Hartman's message of Di Nov 03 19:47:53 +0100 2009:
> I don't think start-stop-daemon  can create the pid file because these process
> fork and daemon themselves.
You can use the -n option for that.

Best regards,
Michael



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Michael Stapelberg <michael+db20090501@...> writes:
> Excerpts from Sam Hartman's message of Di Nov 03 19:47:53 +0100 2009:

>> I don't think start-stop-daemon can create the pid file because these
>> process fork and daemon themselves.

> You can use the -n option for that.

The -n option to start-stop-daemon does not create a PID file.  It changes
the matching logic for finding the process to kill (to use logic that
isn't allowed by Debian Policy).

start-stop-daemon cannot generate PID files for daemons that background
themselves.  It has no idea what the final PID file is.  The daemon has to
do so directly.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Stapelberg-15]

Hi Russ,

Excerpts from Russ Allbery's message of Mi Nov 04 00:08:52 +0100 2009:
> > You can use the -n option for that.
> The -n option to start-stop-daemon does not create a PID file.  It changes
> the matching logic for finding the process to kill (to use logic that
> isn't allowed by Debian Policy).
Correct, but I meant using -n for krb5kdc, which will then not fork/background
itself.

Best regards,
Michael



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sam Hartman-3]

Russ, thoughts on this?



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Sam Hartman <hartmans@...> writes:

> Russ, thoughts on this?

I'm reluctant to run daemons in non-forking mode when everyone else uses
the other mode.  It feels like the right solution would be to teach those
daemons to write out their own PID files; that code is generally quite
simple and most long-running daemons have that capability for exactly that
reason.  That way we also benefit everyone else who uses MIT Kerberos as
well, although it's more work.  I'm pretty sure upstream would take such a
patch.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Stapelberg-15]

Hi,

Excerpts from Russ Allbery's message of Mi Nov 04 19:51:26 +0100 2009:
> the other mode.  It feels like the right solution would be to teach those
> daemons to write out their own PID files; that code is generally quite
> simple and most long-running daemons have that capability for exactly that
> reason.  That way we also benefit everyone else who uses MIT Kerberos as
> well, although it's more work.  I'm pretty sure upstream would take such a
> patch.
That would be OK for me, too. Do you want to write the patch or should I do it?

Best regards,
Michael



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Michael Stapelberg <michael+db20090501@...> writes:
> Excerpts from Russ Allbery's message of Mi Nov 04 19:51:26 +0100 2009:

>> the other mode.  It feels like the right solution would be to teach
>> those daemons to write out their own PID files; that code is generally
>> quite simple and most long-running daemons have that capability for
>> exactly that reason.  That way we also benefit everyone else who uses
>> MIT Kerberos as well, although it's more work.  I'm pretty sure
>> upstream would take such a patch.

> That would be OK for me, too. Do you want to write the patch or should I
> do it?

If you have time, it would probably be faster for you to do it.  I can
submit it upstream and see about getting it incorporated there afterwards
(and we can carry it in the Debian package until the next release if
upstream takes it).

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Michael Stapelberg-15]

Hi,

Excerpts from Russ Allbery's message of Mi Nov 04 20:02:12 +0100 2009:
> If you have time, it would probably be faster for you to do it.  I can
> submit it upstream and see about getting it incorporated there afterwards
> (and we can carry it in the Debian package until the next release if
> upstream takes it).
You can find the patches attached to this mail. Please have a look if they
work for you. What is still missing is a way to specify the destination folder
using autoconf (I’m not good at autoconf, so this would take me a long time).
Currently, /var/run/krb5kdc.pid and /var/run/kadmind.pid are hard-coded (and
don’t use ${prefix} either).

Best regards,
Michael

[Russ Allbery-2]

Michael Stapelberg <michael+db20090501@...> writes:

> You can find the patches attached to this mail. Please have a look if
> they work for you. What is still missing is a way to specify the
> destination folder using autoconf (I’m not good at autoconf, so this
> would take me a long time).  Currently, /var/run/krb5kdc.pid and
> /var/run/kadmind.pid are hard-coded (and don’t use ${prefix} either).

Hm, why did you use open and write instead of fopen and fprintf?  It would
have saved some code to use stdio, I think.

I suspect that upstream is going to want this to be a command-line option,
which would also resolve how to specify where to write the PID file,
rather than changing the default behavior.

I'm not sure what makes the most sense to do in the event of an error
writing out the PID file.  I usually just log an error and continue in the
case of something like that rather than exit fatally.  But upstream can
always change that as they incorporate the patch.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sam Hartman-3]

I'll argue in the upstream discussion that this should be a default
behavior change where failure to write the pid file is non-fatal.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...