Running scheduled maintenance in quiet mode

Clement Moyroud· Mar 29, 2021, 16:45 UTC · lore

Hello,

Now that Git v2.31.0 has the fix for 'git maintenance register' on bare repositories, I've enabled it. I'm now getting a fairly useless daily e-mail with a couple of hashes listed (no other info).

I'd like to disable this e-mail and get the configuration to stick - changing my Crontab with either --quiet or a /dev/null redirect works, but the next time 'git maintenance start' is called, this will be rewritten.

I could not find a 'maintenance.quiet' option (or similar) in the config. Is there a way to do this currently?

Thanks,

Clément

Derrick Stolee· Mar 29, 2021, 19:14 UTC · re: Clement Moyroud · lore

Re: Running scheduled maintenance in quiet mode

On 3/29/2021 12:45 PM, Clement Moyroud wrote:

Show 5 quoted lines

> Hello,
> 
> Now that Git v2.31.0 has the fix for 'git maintenance register' on
> bare repositories, I've enabled it. I'm now getting a fairly useless
> daily e-mail with a couple of hashes listed (no other info).

Thanks for your interest in the feature! Sorry this is a frustrating experience.

> I'd like to disable this e-mail and get the configuration to stick -
> changing my Crontab with either --quiet or a /dev/null redirect works,
> but the next time 'git maintenance start' is called, this will be
> rewritten.

You are right about that. We could alter the implementation of 'start', and the only downside is that you would need to rerun the command to avoid those problems.

For now, you can stick to 'git maintenance register' instead of 'start' so the crontab schedule is not overwritten.

> I could not find a 'maintenance.quiet' option (or similar) in the
> config. Is there a way to do this currently?

This could also be an interesting workaround. To be distinct from the crontab approach, it would probably be necessary to also make the `git maintenance run --auto` output quiet by default, too.

I'm on the side of modifying the crontab schedule. I'd like to hear other opinions before starting the work, though.

Thanks, -Stolee

Ævar Arnfjörð Bjarmason· Mar 30, 2021, 09:16 UTC · re: Derrick Stolee · lore

Re: Running scheduled maintenance in quiet mode

On Mon, Mar 29 2021, Derrick Stolee wrote:

Show 31 quoted lines

> On 3/29/2021 12:45 PM, Clement Moyroud wrote:
>> Hello,
>> 
>> Now that Git v2.31.0 has the fix for 'git maintenance register' on
>> bare repositories, I've enabled it. I'm now getting a fairly useless
>> daily e-mail with a couple of hashes listed (no other info).
>
> Thanks for your interest in the feature! Sorry this is a
> frustrating experience.
>
>> I'd like to disable this e-mail and get the configuration to stick -
>> changing my Crontab with either --quiet or a /dev/null redirect works,
>> but the next time 'git maintenance start' is called, this will be
>> rewritten.
>
> You are right about that. We could alter the implementation of
> 'start', and the only downside is that you would need to rerun
> the command to avoid those problems.
>
> For now, you can stick to 'git maintenance register' instead of
> 'start' so the crontab schedule is not overwritten.
>
>> I could not find a 'maintenance.quiet' option (or similar) in the
>> config. Is there a way to do this currently?
>
> This could also be an interesting workaround. To be distinct from
> the crontab approach, it would probably be necessary to also make
> the `git maintenance run --auto` output quiet by default, too.
>
> I'm on the side of modifying the crontab schedule. I'd like to
> hear other opinions before starting the work, though.

The behavior of crond on *nix systems of e-mailing on output and ignoring exit codes is probably one of the worst design choices of that family of systems.

I think the only sane way to deal with that is to run the relevant program through something like chronic or any of the numerous other "buffer up cmd output and check exit code, spew if non-zero" wrappers: https://habilis.net/cronic/

We could even ship such a wrapper ourselves, or ship chronic itself (it's like ~20 lines of Perl).

Down the road of catering to cron's behavior in individual programs lies madness. Instead being able to run your program, emit diagnostics output and decide on the exit code at the end you end up having to decide at any given leaf node in your program whether what you have there is important enough to impact the eventual exit code, because otherwise you should be quiet least cron sends an E-Mail.

You essentially end up re-implementing something like chronic in your program. I've seen *way* too many such hacks of buffering output until the end that could have trivially been implemented via chronic.