filelock fails to acquire lock in sub-process launched via callr?

[kevinushey]

library(callr)
library(filelock)

file <- tempfile("lockfile-")
filelock::lock(file)
#> Lock on '/private/tmp/Rtmp3hJ9XM/lockfile-1009c4e2ac322'

callr::r(function() {
  file <- tempfile("lockfile-")
  filelock::lock(file)
})
#> Unlocked lock on '/private/tmp/Rtmpr7Jryb/lockfile-100aa7989c5ff'

^{Created on 2021-02-12 by the reprex package (v1.0.0)}

Is this the expected behavior?

[kevinushey]

With this script I see the expected behavior:

library(filelock)

# acquire lock in this process
file <- tempfile("lockfile-")
lock <- filelock::lock(file)
print(lock)

# try acquiring lock on same file in sub-process
code <- substitute({
  library(filelock)
  lock <- filelock::lock(file, timeout = 0)
  if (is.null(lock))
    stop("failed to acquire lock")
}, list(file = file))

# write to separate script and run
script <- tempfile("lock-", fileext = ".R")
writeLines(deparse(code), con = script)
R <- file.path(R.home("bin"), "R")
system2(R, c("-s", "-f", shQuote(script)))

That is:

> system2(R, c("-s", "-f", shQuote(script)))
Error: failed to acquire lock
Execution halted

[gaborcsardi]

A lock is an external pointer, you cannot copy it to another process. A lock belongs to a process, in the first place.

Locking in a sub-process does work of course, many filelock test cases are written that way, actually.

What is the problem you want to solve?

[kevinushey]

Sorry, this was my mistake 😞 . In this:

callr::r(function() {
  file <- tempfile("lockfile-")
  filelock::lock(file)
})
#> Unlocked lock on '/private/tmp/Rtmpr7Jryb/lockfile-100aa7989c5ff'

I thought the output here was from within the sub-process; that is, I thought the sub-process was reporting that the lock wasn't actually acquired. This makes it clear that everything is working as intended:

> callr::r(function() {
+   file <- tempfile("lockfile-")
+   capture.output(print(filelock::lock(file)))
+ })
[1] "Lock on ‘/private/tmp/RtmpJT8T2e/lockfile-1084646fed2ed’"

Ultimately, my goal here was to provide a user with some test code using the filelock package to see if advisory locks were working as expected on their NFS volume...

[gaborcsardi]

Ultimately, my goal here was to provide a user with some test code using the filelock package to see if advisory locks were working as expected on their NFS volume...

Did they? My understanding is that on recent Linux kernels they should.

[kevinushey]

Evidently so, although in this case it was a user on macOS. We've seen issues with advisory file locks not working on some specific NFS instances either because they were too old or misconfigured in some way, though.

[gaborcsardi]

Do you think it would be useful to detect when advisory locks are not working, and fall back to another mechanism?

[kevinushey]

That could be useful. For what it's worth, In RStudio, we have a separate locking scheme that relies on the atomicity of ::link(), which should be atomic even for older NFS systems. (Handling "stale" or "orphaned" locks becomes more challenging though)