Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
forwarded 550781 http://krbdev.mit.edu/rt/Ticket/Display.html?id=6618
thanks
Michael Stapelberg michael+db20090...@stapelberg.de 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).
I think that upstream is likely to want this to be optional, or at least I
think that's the first pass approach to take. I submitted a variation of
your patches upstream as RT #6618 that add a command-line option instead
of hard-coding a path and that use stdio (it's a bit easier to read).
Attached is the patch I submitted, for reference.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Index: src/kdc/krb5kdc.M
===
--- src/kdc/krb5kdc.M (revision 23554)
+++ src/kdc/krb5kdc.M (working copy)
@@ -48,6 +48,9 @@
.I realm
] [
.B \-n
+] [
+.B \-P
+.I pid_file
]
.br
.SH DESCRIPTION
@@ -134,6 +137,14 @@
operation, you should always allow the KDC to place itself in
the background.
.PP
+The
+.B \-P
+.I pid_file
+option tells the KDC to write its PID (followed by a newline) into
+.I pid_file
+after it starts up. This can be used to identify whether the KDC is still
+running and to allow init scripts to stop the correct process.
+.PP
The KDC may service requests for multiple realms (maximum 32 realms). The
realms are listed on the command line. Per-realm options that can be
specified on the command line pertain for each realm that follows it and are
Index: src/kdc/main.c
===
--- src/kdc/main.c (revision 23553)
+++ src/kdc/main.c (working copy)
@@ -59,6 +59,7 @@
#include signal.h
#include errno.h
#include netdb.h
+#include unistd.h
#include k5-int.h
#include com_err.h
@@ -90,6 +91,7 @@
void finish_realms (void);
static int nofork = 0;
+static const char *pid_file = NULL;
static int rkey_init_done = 0;
#ifdef POSIX_SIGNALS
@@ -558,7 +560,7 @@
void
usage(char *name)
{
-fprintf(stderr, usage: %s [-x db_args]* [-d dbpathname] [-r dbrealmname]\n\t\t[-R replaycachename] [-m] [-k masterenctype] [-M masterkeyname]\n\t\t[-p port] [/]\n
+fprintf(stderr, usage: %s [-x db_args]* [-d dbpathname] [-r dbrealmname]\n\t\t[-R replaycachename] [-m] [-k masterenctype] [-M masterkeyname]\n\t\t[-p port] [-P pid_file] [/]\n
\nwhere,\n\t[-x db_args]* - Any number of database specific arguments. Look at\n
\t\t\teach database module documentation for supported\n\t\t\targuments\n,
name);
@@ -634,7 +636,7 @@
* Loop through the option list. Each time we encounter a realm name,
* use the previously scanned options to fill in for defaults.
*/
-while ((c = getopt(argc, argv, x:r:d:mM:k:R:e:p:s:n4:X3)) != -1) {
+while ((c = getopt(argc, argv, x:r:d:mM:k:R:e:P:p:s:n4:X3)) != -1) {
switch(c) {
case 'x':
db_args_size++;
@@ -723,6 +725,8 @@
case 'R':
rcname = optarg;
break;
+case 'P':
+pid_file = optarg;
case 'p':
if (default_udp_ports)
free(default_udp_ports);
@@ -905,6 +909,23 @@
finish_realms();
return 1;
}
+if (pid_file != NULL) {
+FILE *file;
+unsigned long pid;
+
+file = fopen(pid_file, w);
+if (file == NULL) {
+kdc_err(kcontext, errno, while creating PID file);
+finish_realms();
+return 1;
+}
+pid = (unsigned long) getpid();
+if (fprintf(file, %ld\n, pid) 0 || fclose(file) == EOF) {
+kdc_err(kcontext, errno, while writing PID file);
+finish_realms();
+return 1;
+}
+}
krb5_klog_syslog(LOG_INFO, commencing operation);
if (nofork)
fprintf(stderr, %s: starting...\n, kdc_progname);
Index: src/kadmin/server/ovsec_kadmd.c
===
--- src/kadmin/server/ovsec_kadmd.c (revision 23553)
+++ src/kadmin/server/ovsec_kadmd.c (working copy)
@@ -134,6 +134,7 @@
[-passwordserver]
#endif
[-port port-number]\n
+\t\t[-P pid_file]\n
\nwhere,\n\t[-x db_args]* - any number of database specific arguments.\n
\t\t\tLook at each database documentation for supported arguments\n
);
@@ -216,6 +217,7 @@
char *errmsg;
int i;
int strong_random = 1;
+const char *pid_file = NULL;
kdb_log_context *log_ctx;
@@ -286,6 +288,11 @@
usage();
params.kadmind_port = atoi(*argv);
params.mask |= KADM5_CONFIG_KADMIND_PORT;
+} else if
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
Michael Stapelberg michael+db20090...@stapelberg.de 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 (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
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
krb5-pid.patch
Description: Binary data
krb5-pid-kadmind.patch
Description: Binary data
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
Russ, thoughts on this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
Sam Hartman hartm...@debian.org 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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
Michael Stapelberg michael+db20090...@stapelberg.de 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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
Michael Stapelberg michael+db20090...@stapelberg.de 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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550781: krb5-kdc: missing pidfiles for krb5kdc and kadmind
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
