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

From: Jeff King <peff@peff.net>
Date: May 11, 2026, 20:22 UTC
Message-ID: <20260511202258.GD22912@coredump.intra.peff.net>
In-Reply-To: <agF6Q-z1SuTL1xXs@pks.im>

On Mon, May 11, 2026 at 08:42:11AM +0200, Patrick Steinhardt wrote:

Show 7 quoted lines

> In any case, I also agree with Stolee that it may have unintended
> consequences to unconditionally reassign tempfiles to the child process
> when daemonizing. It is okay for all current callers, but I'm not sure
> whether future callers would expect this behaviour.
> 
> An alternative would be to explicitly reassign the lockfile's ownership
> in git-maintenance(1). Something like the below patch.

I really think this should be an automatic part of daemonize(), for the reasons I gave earlier in the thread. It's really a lurking problem for any cleanup handler, but lockfiles are the one that is most likely to bite us.

In fact, I thought "git gc --detach" without "--skip-foreground-tasks" had the same bug, but it narrowly avoids it by dropping and reacquiring the lock (!) on either side of the daemonize() call.

So I think you are more likely to avoid unpleasant surprises by baking the behavior into daemonize() rather than requiring each caller to do it manually.

Plus it keeps daemonize() a bit more abstract. It's a noop on Windows, but you can imagine an implementation that does weird platform-specific stuff and doesn't switch pids at all.

-Peff