kadmin incremental propagation full resync multiple processes spawned
Greg Hudson
ghudson at MIT.EDU
Thu Nov 3 14:14:30 EDT 2011
On 11/02/2011 06:11 PM, Paul B. Henson wrote:
> I posted about this a month or two ago and didn't see any responses.
Sorry about that; it's been a busy time.
> A child process is spawned to serve that request: [...]
> That process gets a strange error (which I'm not sure is relevant):
>
> Nov 2 03:50:06 halfy kadmind[20238]: iprop_full_resync_1: pclose(popen)
> failed: Success
It's definitely relevant. This implies the kdb5_util dump command
failed. At that point there are several bugs:
* The error message doesn't say what command it tried to run, nor does
it show the output of the failed command.
* The status code used in the error message is the value of errno, which
is not meaningful if the kdb5_util child returned an exit status (as
opposed to a failure to create an I/O pipe or fork).
* The error is handled by returning from ipropx_resync instead of
exiting, which is why you're getting kadmind process proliferation.
All of these bugs existed in 1.8 and 1.7 (the code hasn't changed); the
new factor is that the dump is failing. Unfortunately, we kind of have
to guess at why. The most obvious candidates are that (1) the path to
kdb5_util is wrong, or (2) the path to the dump file is in a nonexistent
directory.
The path to kdb5_util is determined at build time as
<sbindir>/kdb5_util. You can verify what it is in your build with
"strings /path/to/kadmind | grep kdb5_util".
The path to the dump file is determined as
<localstatedir>/krb5kdc/slave_datatrans_<clienthost>. You can verify
what it is in your build with "strings /path/to/kadmind | grep
datatrans"; make sure the parent directory (<localstatedir>/krb5kdc) exists.
More information about the Kerberos
mailing list