detail file locking
Alan DeKok
aland at deployingradius.com
Wed Nov 24 19:27:00 CET 2021
On Nov 24, 2021, at 12:40 PM, Thor Spruyt <thor.spruyt at telenet.be> wrote:
> With strace I found out the following:
>
> Here the .work file is tried but doesn't exist:
> [pid 14198] open("/opt/radius/var/queue/queue_000/detail.work", O_RDWR <unfinished ...>
> [pid 14198] <... open resumed>) = -1 ENOENT (No such file or directory)
That's fine.
> Next a new file was detected, which is opened (not sure if it's locked):
You should see calls to fcntl() in order to lock the file. That's if you have "locking = true" in the detail file write.
> [pid 14198] openat(AT_FDCWD, "/opt/radius/var/queue/queue_000/detail-000", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY <unfinished ...>
> [pid 14198] <... openat resumed>) = 183
> [pid 14198] getdents(183 <unfinished ...>
> [pid 14198] <... getdents resumed>, /* 3 entries */, 32768) = 96
> [pid 14198] getdents(183 <unfinished ...>
> [pid 14198] <... getdents resumed>, /* 0 entries */, 32768) = 0
It should be locked.
> Here is the file is closed:
> [pid 14198] close(183 <unfinished ...>
> [pid 14198] <... close resumed>) = 0
> [pid 14198] stat("/opt/radius/var/queue/queue_000/detail-000", <unfinished ...>
> [pid 14198] <... stat resumed>{st_mode=S_IFREG|0644, st_size=12294, ...}) = 0
>
> And here the rename happens, but isn't the lock gone due to the close ?
> [pid 14198] rename("/opt/radius/var/queue/queue_000/detail-000", "/opt/radius/var/queue/queue_000/detail.work" <unfinished ...>
> [pid 14198] <... rename resumed>) = 0
Hmm... locks are gone on close. But the source file exfile.c implements an API which handles all of that. It doesn't call close() until all of the locks have been released.
Alan DeKok.
More information about the Freeradius-Users
mailing list