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

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Dec 2, 2025, 22:29 UTC
Message-ID: <CALnO6CB1igUL7nv6ByUmwMRc9tqEvs=18wD81GNpaA=FLpL2vw@mail.gmail.com>
In-Reply-To: <pull.2011.git.1764688047077.gitgitgadget@gmail.com>

On Tue, Dec 2, 2025 at 10:07 AM Paulo Casaretto via GitGitGadget <gitgitgadget@gmail.com> wrote:

Show 33 quoted lines

>
> From: Paulo Casaretto <pcasaretto@gmail.com>
>
> When a lock file is held, it can be helpful to know which process owns
> it, especially when debugging stale locks left behind by crashed
> processes. Add an optional feature that creates a companion .lock.pid
> file alongside each lock file, containing the PID of the lock holder.
>
> The .lock.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 if the PID from the .pid
> file is still running using kill(pid, 0). This allows providing
> context-aware error messages. With PID info enabled:
>
>   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.
>
> Without PID info (default):
>
>   Another git process seems to be running in this repository.
>   Wait for it to finish, or remove the lock file to continue.
>
> The feature is opt-in via GIT_LOCK_PID_INFO=1 environment variable.
>
> Signed-off-by: Paulo Casaretto <pcasaretto@gmail.com>

Sounds interesting. I think by the time I wish I knew what else was using the lockfile, it's too late for me to alter my environment. Perhaps (in addition to allowing the environment opt-in) we could opt-in via configuration? Or is this really only useful, say, on the server side where the environment is carefully controlled? I don't relish putting this variable into my environment to take advantage of something that looks very useful.

Are there downsides that make it necessary to be opt-in? I also imagine this could be a useful default; occasionally folks at work hit something similar and ask "what's up with that?"

Only other thing is: just because a process X is running doesn't mean it was the one holding the lock, right? Since PIDs can be reused.

-- 
D. Ben Knoble