From: D. Ben Knoble Date: Thu, 08 Jan 2026 14:19:36 GMT Subject: Re: [PATCH v4] lockfile: add PID file for debugging stale locks Message-ID: In-Reply-To: On Wed, Jan 7, 2026 at 8:59 PM Junio C Hamano wrote: > > "Paulo Casaretto via GitGitGadget" 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. [snip] > > 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). Yep. I mentioned this back in : > just because a process X is running doesn't mean > it was the one holding the lock, right? Since PIDs can be reused. which seems to have been ignored, but I'm glad to know I didn't make this concern up out of thin air :) Best, -- D. Ben Knoble