lock failed when program restart after crash about lockfile

[tim-seoss]

The same issue is present on Linux. This race also gets lost frequently for system services (which start up during system boot, and so often have long-lived processes with similar PIDs present on subsequent boots), which then fail on the next system boot.

You could fix this by:

. Storing as much as you can (on the given OS) of:

• hostname
• process start time
• process executable path
• pid

You then:

Always consider locks valid if the hostname is different from that stored in the lock file (since you can't tell if the process is still running)

If the hostname matches, then only consider the lock valid if the PID, process start time, and executable (or as many of those as you have on the given OS) is present.

Maybe store the lock file contents as JSON?

I can create some proof-of-concept code for Linux if you're interested?

[nightlyone]

Thanks @tim-seoss for the offer! Would like to see such code. I esp. look for ideas on how to parse existing lock files not having that information and do the migration transparently.

[Aulilino]

First, thanks a lot for your lib.

I am confused about this issue. The core of "lock file" is LOCK the file by current process, not just write the pid into file. Due to the file is locked, the certain instance of program must be running. Besides the process dies, the lock will disappear and the other instance can run and relock the file.

By reading the code, it seems lockfile does not use the mechanism above. Maybe we should check the process which pid written in the pid file is the certain process or not, using the lib.

[tim-seoss]

@Aulilino To clarify, the lib currently (or at least when I last checked a year ago) made the following assumption:

1. If there is a process in existence with the same PID as in the lock file, then the lock is still valid (because the process which created the file must still be running, and therefore the lock should be honoured).
2. If there is not a process in existence with the same PID as in the lock file, then the lock is no longer valid, and can be reissued to the calling process.

These assumptions break if:

. The process ID has been reallocated to another process entirely.
. The PID gets reallocated to another invocation of the same binary (e.g. typically because of a reboot, but this can also happy less frequently by chance in normal operation).
. The filesystem containing the lock is visible across PID namespaces (e.g. via a network filesystem, or container boundary), so that a still-running process which holds the lock is potentially invisible to the calling process.

[nightlyone]

@tim-seoss thanks for the analysis. The last point about pid namespaces might be a deal breaker for many people.

So I believe this should be documented in a limitations section of the readme as well as in the package doc.

Care to send a pull request for either of these?

[nightlyone]

frozen due to age.