On 11/03/2011 05:27 PM, Paul B. Henson wrote:
> So kdb5_util is failing sometimes <sigh>. Are any of these bugs
> perchance on the shortlist for getting resolved :)? Presumably if the
> kdb5_util failure details were logged it might be blindingly obvious
> what's going on, or at least a step closer to resolution.
Producing a good log message will take a bit of actual work, but fixing
the error handling is a trivial patch, which I've attached (not tested,
but it's very simple).
> could it be that kdb5_util is failing to lock the database because
> kadmind is monopolizing it resulting in the dump failing?
That's a good theory. I don't know if you've been involved in previous
discussions about our DB2 locking, but since POSIX doesn't provide a way
to acquire a file lock with a timeout, we just try once a second for
five seconds, which doesn't provide any kind of fairness guarantee,
unfortunately.
diff --git a/src/kadmin/server/ipropd_svc.c b/src/kadmin/server/ipropd_svc.c
index d732098..0e45f6a 100644
--- a/src/kadmin/server/ipropd_svc.c
+++ b/src/kadmin/server/ipropd_svc.c
@@ -380,7 +380,7 @@ ipropx_resync(uint32_t vers, struct svc_req *rqstp)
_("%s: pclose(popen) failed: %s"),
whoami,
error_message(errno));
- goto out;
+ _exit(1);
}
DPRINT(("%s: exec `kprop -f %s %s' ...\n",
@@ -401,7 +401,7 @@ ipropx_resync(uint32_t vers, struct svc_req *rqstp)
_("%s: exec failed: %s"),
whoami,
error_message(errno));
- goto out;
+ _exit(1);
}
default: /* parent */
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
