On Thu, Dec 31, 2015 at 1:08 AM, Greg Hudson <ghud...@mit.edu> wrote:
> On 12/30/2015 04:28 PM, Isaac Boukris wrote:
>> [pid 21891]
>> fcntl64(6</home/admin/git/krb5/src/lib/krb5/ccache/testdir/db.kadm5.lock>,
>> F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
>> l_len=-5230051357888610304}) = -1 EINVAL (Invalid argument)
>> [pid 21891]
>> fcntl64(6</home/admin/git/krb5/src/lib/krb5/ccache/testdir/db.kadm5.lock>,
>> F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}
>
> Unfortunately, I can't really tell what's going on. In ofdlock(), we
> pass the same struct flock pointer to both fcntl() invocations when we
> fall back to F_SETLKW, so I don't know why the first invocation is
> reported a garbage l_len. I also don't know why the second invocation
> is blocking; did the first invocation somehow obtain a lock despite
> returning EINVAL? I can't find any search results about a known kernel
> or glibc bug which might explain this odd behavior.
Strange indeed, it does look like the fd is locked:
# cat /proc/24040/fdinfo/6
pos: 0
flags: 02000002
mnt_id: 57
lock: 1: POSIX ADVISORY READ 24040 fd:00:1195813 0 EOF
I've pasted a longer output of strace at:
http://pastebin.com/Rw8nvjCZ
>> PYTHONPATH=../../util VALGRIND="" python ./t_gss_sample.py
>> *** Failure: /home/admin/git/krb5/src/appl/gss-sample/gss-client
>> failed with code 1.
>
> There should have been some additional messages explaining how to get
> more information from a failing Python test; that information (and
> perhaps more) is needed to figure out why this is failing for you.
So I looked at the testlog file and noticed it got confused because my
host had two DNS records with different names (round robin).
Once I removed the additional name the 'make check' succeeded.
Thanks!
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
