Konstantin Ryabitsev wrote:
> Well, it may also not be something that's the responsibility of public-inbox
> either, e.g. other long-running daemons don't perform such checks. We can just
> issue a reload after we've done repacking.
The less operational knowledge required, the better; especially
On Tue, Sep 21, 2021 at 07:06:53PM +, Eric Wong wrote:
> Was this from /all/ (ALL.git using batch-file) or Gcf2?
I believe this was from Gcf2, though I can't go back and check,
unfortunately.
> The old stuff has timers to do periodic cleanup, but the new
> stuff is trickier as the cost of a
Konstantin Ryabitsev wrote:
> Hello:
>
> A large git repack job that ran over the weekend revealed a minor problem --
> public-inbox daemon processes will hold on to deleted pack files until they
> are restarted. Is there any way to gracefully recognize and handle this
> condition? It's not
Hello:
A large git repack job that ran over the weekend revealed a minor problem --
public-inbox daemon processes will hold on to deleted pack files until they
are restarted. Is there any way to gracefully recognize and handle this
condition? It's not quite benign, as this ended up keeping 40GB+
