From: Jacob Keller Date: Mon, 11 May 2026 23:58:34 GMT Subject: Re: unexpected auto-maintenance, was Re: git hogs the CPU, RAM and storage despite its config Message-ID: In-Reply-To: <20260511203502.GA25510@coredump.intra.peff.net> On 5/11/2026 1:35 PM, Jeff King wrote: > On Mon, May 11, 2026 at 01:21:37PM -0700, Jacob Keller wrote: > >>> - If both claim ownership, it's mostly OK, because they'll both try to >>> unlink() which is idempotent-ish. Though there is a bad sequence >>> where we delete somebody _else's_ lock, like: >>> >>> 1. Parent forks, but has not yet reassigned. >>> >>> 2. Child calls reassign to take ownership. Now both have >>> ownership. >>> >>> 3. Signal kills both parent and child, so they enter cleanup >>> code. >>> >>> 4. One of them (let's say the parent) deletes the lockfile. >>> >>> 5. Some other unrelated process (let's call it "git other") takes >>> the lock. >>> >>> 6. The child deletes the lockfile. >>> >>> And at that point "git other" thinks it holds the lock, but it >>> doesn't. It's quite an unlikely sequence in practice, though, I'd >>> think. >>> >>> - If neither claims ownership and a signal kills both, then nobody >>> cleans up the lock and it is left in place. This is annoying, but >>> also something that can happen occasionally anyway (kill -9, etc). >>> >>> I don't have an easy suggestion for making it more atomic, though. You >>> could choose one or the other direction using some synchronization >>> between the two (e.g., child reassigns only after parent signals over a >>> pipe that it has relinquished), but it's all kind of ugly. >>> >> Ya, that seems really ugly. My first thought was some way to disable >> signals temporarily, but I am guessing that either has no good way to do >> it or would introduce even more issues. Plus there is always kill -9... > > I guess the parent could relinquish control by reassigning to "0" before > even calling fork(), and then taking it back if fork() fails. And then > worst case is that nobody cleans up the lock (if the child is killed > before taking control), but that's the least-bad outcome from a > correctness perspective (though still annoying). > > -Peff This seems simpler than the suggestion of a pipe signal, and the worst result is only the version that is possible no matter what if there is a well timed kill -9.