From: D. Ben Knoble Date: Tue, 02 Dec 2025 22:29:40 GMT Subject: Re: [PATCH] lockfile: add PID file for debugging stale locks Message-ID: In-Reply-To: On Tue, Dec 2, 2025 at 10:07 AM Paulo Casaretto via GitGitGadget wrote: > > From: Paulo Casaretto > > 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 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