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

[Jacob Keller <jacob.e.keller@intel.com>]

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.