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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
