GitLab

os: Lock file: No link phase, never unlink foreign lock, hardening of abnormal situations

Calling unlink(2) on a file we do not own is fundamentally racy on UNIX
systems, so remove such calls, renouncing to break stale locks from inside, and
just give the best possible reporting to the user.

Simplify the code by replacing the two-phase procedure, with creation of a
temporary lock file and then the use of link(2) to put it in place, with direct
exclusive creation of the lock file (more details below).

Also, limit retries to 3 on the whole, instead of 3+3, with only 1s between
each retry instead of 2, limiting the whole process length to ~3s. Retries are
now here only for waiting for a potential existing server to shut down and to
possibly give better reporting of what's going on to the user.

***

First creating a temporary file with open(2) with flags O_CREAT | O_EXCL and
then moving it atomically in place with link(2) has only a single advantage: To
ensure that any lock file that is in place has the right content (here,
length). This allows to detect more types of stale lock files (i.e., ones that
don't have the expected length). However, the only use of such an information
was to unlink(2) such a file, and unlink(2) is inherently racy (in bad
circumstances, it can destroy a legitimate lock file established by another
server). Once unlink(2) calls on foreign locks are removed, this advantage is
no more, and the code can be simplified by removing the link(2) phase
altogether.

Signed-off-by: Olivier Certner <olce.freedesktop@certner.fr>