Re: [PATCH v4] lockfile: add PID file for debugging stale locks

>
> "Paulo Casaretto via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > The PID file is created when a lock is acquired (if enabled), and
> > automatically cleaned up when the lock is released (via commit or
> > rollback). The file is registered as a tempfile so it gets cleaned up
> > by signal and atexit handlers if the process terminates abnormally.
> >
> > When a lock conflict occurs, the code checks for an existing PID file
> > and, if found, uses kill(pid, 0) to determine if the process is still
> > running. This allows providing context-aware error messages:
> >
> >   Lock is held by process 12345. Wait for it to finish, or remove
> >   the lock file to continue.
> >
> > Or for a stale lock:
> >
> >   Lock was held by process 12345, which is no longer running.
> >   Remove the stale lock file to continue.
>
> Two additional thoughts.
>
>  * 12345 may be running as your kill(12345,0) did not fail, but that
>    may be a process different from the one that held the lock and
>    then died without cleaning up.

> > The feature is controlled via core.lockfilePid configuration (boolean).
> > Defaults to false. When enabled, PID files are created for all lock
> > operations.
> >
> > Existing PID files are always read when displaying lock errors,
> > regardless of the core.lockfilePid setting. This ensures helpful
> > diagnostics even when the feature was previously enabled and later
> > disabled.
>
> This makes it even more easily triggerable to notice a running
> process that happens to be reusing a process ID an old process used
> to have (i.e. the first "thought" above---the phrasing of the
> message needs to be carefully thought out).