When there is a lockfile timeout, show the pid of the process that holds the lock

[thaljef]

Maybe even offer to steal the lock if the process appears dead. Beware of NFS situations, where the process could be on another server.

[celogeek]

Also a good option could be --retry-forever
So if we can't get the lock, we retry until we got it.

We have made automatic injection system, that grep the error and loop until it works.
We a --retry-forever option it would ease that situation.

[thaljef]

Retrying forever seems a bit dubious to me. There is a PINTO_LOCKFILE_TIMEOUT environment variable you can set though. Not sure if that is documented.

[celogeek]

can we set PINTO_LOCKFILE_TIMEOUT=-1 or =0 mean forever ?

The forever is more because we have numerous to work on pinto, and it has no queue for processing. So trying to steal lock as soon as possible could be great. But we need to complete the operation under an automatic process.

[cakirke]

looks like File::NFSLock supports stale_lock_timeout, could expose it via PINTO_ env and document interaction if ultimate goal is not "wait forever" but "wait suitably long, then steal the lock"

also, with a (very) quick look at File::NFSLock internals, i don't see it setting the holder pid on failure - a chicken/egg issue for reporting it on failure

[thaljef]

can we set PINTO_LOCKFILE_TIMEOUT=-1 or =0 mean forever ?

Yes, it looks like 0 means forever.

[thaljef]

i don't see it setting the holder pid on failure - a chicken/egg issue for reporting it on failure.

I think we'll just have to parse that from the contents of the lock file itself (or patch File::NFSLock).

[cakirke]

proposed hookbot/File-NFSLock#3, if accepted, it should cover the reporting issue.
continuing with the stale lock/steal lock portion of this.