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