We have a commercial application we've been running for years on an
openafs-1.4.14 client on a RedHat Linux box. This week we upgraded the
client to 1.6.9, but quickly had to revert. The difference has to do with
file locking. The section of strace output below shows the behavior in the
old client:
open("/afs/[OurCell]/pkg/[application_path]/msgdir.msg", O_RDONLY) = 8
fcntl(8, F_SETFD, FD_CLOEXEC) = 0
fcntl(8, F_GETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0, pid=0}) = 0
fcntl(8, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
after which the application proceeds with total succss.
The corresponding section of the 1.6.9 client's strace of the same
application on the same machine shows:
open("/afs/[OurCell]/pkg/[application_path]/msgdir.msg", O_RDONLY) = 8
fcntl(8, F_SETFD, FD_CLOEXEC) = 0
fcntl(8, F_GETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0, pid=0}) = 9
close(8) = 0
write(1, "\n", 1) = 1
write(1, "UNABLE TO OPEN/READ MESSAGE FILE"..., 53) = 53
After the somewhat misleading message, the application closes. The
difference starts in the 3rd line, where the old client reports no extant
locks on the file, but the 1.6.9 client reports an existing exclusive lock.
For what it's worth, other 1.6.9 clients exhibit the same behavior, so
it's not like this one client had an outstanding lock of the file.
Was there some change in file locking semantics that would make sense of
this? Does this application tickle a corner case error in openafs's file
locking, or does more rigorous lock handling in the newer client expose a
bug in the application? I have tried to replicate the failure with a very
simple C program with no success, but that mostly indicates I'm not sure
what I'm testing for.
Thoughts? Suggestions? Thanks,
--
todd_le...@unc.edu
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
