Re: unexpected auto-maintenance, was Re: git hogs the CPU, RAM and storage despite its config

[Jeff King <peff@peff.net>]

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