I see a second open of the fd in the strace… apparently, in some circumstances, it is resulting in a double-read. > On Mar 18, 2018, at 3:51 PM, Richard Basch wrote: > > This might indicate it did a double read of the config file where the data was already consumed… second read may have failed. > But why sporadically? > >> On Mar 18, 2018, at 3:44 PM, Richard Basch wrote: >> >> There was one other small nuance in my test… I used a custom kdc.conf, specified as a bash sub-command: >> >> KRB5_KDC_PROFILE=<(printf …) … >> >> That said, the strace showed it reading from /dev/fd/63 with data returned such as the database_name, so there is no obvious failure on the shell to provide the fd or that the fd was inaccessible. (The only reason I use this syntax to generate a custom KRB5_KDC_PROFILE is to circumvent defining the kadm5_dict_file and loading some of the kadm5 hooks which don’t apply for the kinit operations - this method significantly improves the performance, when it doesn’t sporadically fail.) >> >> >>> On Mar 18, 2018, at 3:31 PM, Greg Hudson via RT wrote: >>> >>> I tried running the same script (inside "make testrealm", and gwithout >>> the env var settings since that's already taken care of) and >>> unfortunately couldn't reproduce the issue, with either master or 1.15. >>> >>> Knowing that it was trying to read the stash file from the unconfigured >>> location is interesting; it suggests perhaps an earlier failure to read >>> $KRB5_KDC_CONFIG or something. But I still can't come up with a theory >>> as to what the bug might be. >>> _______________________________________________ >>> krb5-bugs mailing list >>> krb5-bugs@mit.edu >>> https://mailman.mit.edu/mailman/listinfo/krb5-bugs >> >