diff mbox series

[v3,4/4] maintenance: optionally use systemd timers on Linux

Message ID 20210520221359.75615-5-lenaic@lhuard.fr (mailing list archive)
State New, archived
Headers show
Series maintenance: use systemd timers on Linux | expand

Commit Message

Lénaïc Huard May 20, 2021, 10:13 p.m. UTC
The existing mechanism for scheduling background maintenance is done
through cron. On Linux systems managed by systemd, systemd provides an
alternative to schedule recurring tasks: systemd timers.

The main motivations to implement systemd timers in addition to cron
are:
* cron is optional and Linux systems running systemd might not have it
  installed.
* The execution of `crontab -l` can tell us if cron is installed but not
  if the daemon is actually running.
* With systemd, each service is run in its own cgroup and its logs are
  tagged by the service inside journald. With cron, all scheduled tasks
  are running in the cron daemon cgroup and all the logs of the
  user-scheduled tasks are pretended to belong to the system cron
  service.
  Concretely, a user that doesn’t have access to the system logs won’t
  have access to the log of its own tasks scheduled by cron whereas he
  will have access to the log of its own tasks scheduled by systemd
  timer.
  Although `cron` attempts to send email, that email may go unseen by
  the user because these days, local mailboxes are not heavily used
  anymore.

In order to schedule git maintenance, we need two unit template files:
* ~/.config/systemd/user/git-maintenance@.service
  to define the command to be started by systemd and
* ~/.config/systemd/user/git-maintenance@.timer
  to define the schedule at which the command should be run.

Those units are templates that are parameterized by the frequency.

Based on those templates, 3 timers are started:
* git-maintenance@hourly.timer
* git-maintenance@daily.timer
* git-maintenance@weekly.timer

The command launched by those three timers are the same as with the
other scheduling methods:

git for-each-repo --config=maintenance.repo maintenance run
--schedule=%i

with the full path for git to ensure that the version of git launched
for the scheduled maintenance is the same as the one used to run
`maintenance start`.

The timer unit contains `Persistent=true` so that, if the computer is
powered down when a maintenance task should run, the task will be run
when the computer is back powered on.

Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr>
---
 Documentation/git-maintenance.txt |  57 +++++++++-
 builtin/gc.c                      | 181 ++++++++++++++++++++++++++++++
 t/t7900-maintenance.sh            |  66 ++++++++++-
 3 files changed, 294 insertions(+), 10 deletions(-)

Comments

Bagas Sanjaya May 21, 2021, 9:59 a.m. UTC | #1
On 21/05/21 05.13, Lénaïc Huard wrote:
> The existing mechanism for scheduling background maintenance is done
> through cron. On Linux systems managed by systemd, systemd provides an
> alternative to schedule recurring tasks: systemd timers.
> 
> The main motivations to implement systemd timers in addition to cron
> are:
> * cron is optional and Linux systems running systemd might not have it
>    installed.
> * The execution of `crontab -l` can tell us if cron is installed but not
>    if the daemon is actually running.
> * With systemd, each service is run in its own cgroup and its logs are
>    tagged by the service inside journald. With cron, all scheduled tasks
>    are running in the cron daemon cgroup and all the logs of the
>    user-scheduled tasks are pretended to belong to the system cron
>    service.
>    Concretely, a user that doesn’t have access to the system logs won’t
>    have access to the log of its own tasks scheduled by cron whereas he
>    will have access to the log of its own tasks scheduled by systemd
>    timer.

For gender neutrality, we can use he/she instead.

>    Although `cron` attempts to send email, that email may go unseen by
>    the user because these days, local mailboxes are not heavily used
>    anymore.
> 
> In order to schedule git maintenance, we need two unit template files:
> * ~/.config/systemd/user/git-maintenance@.service
>    to define the command to be started by systemd and
> * ~/.config/systemd/user/git-maintenance@.timer
>    to define the schedule at which the command should be run.
> 
> Those units are templates that are parameterized by the frequency.
> 
> Based on those templates, 3 timers are started:
> * git-maintenance@hourly.timer
> * git-maintenance@daily.timer
> * git-maintenance@weekly.timer
> 
> The command launched by those three timers are the same as with the
> other scheduling methods:
> 
> git for-each-repo --config=maintenance.repo maintenance run
> --schedule=%i
> 
> with the full path for git to ensure that the version of git launched
> for the scheduled maintenance is the same as the one used to run
> `maintenance start`.
> 

Wouldn't it be `/path/to/git for-each-repo <options>...`?

> The timer unit contains `Persistent=true` so that, if the computer is
> powered down when a maintenance task should run, the task will be run
> when the computer is back powered on.
> 

The title for this patch implied that users running Linux can choose
between classic crontab or systemd timers. However, the intent of this
patch is we add support for systemd timers. So let's say the title
should be "maintenance: add support for systemd timers on Linux".
Derrick Stolee May 21, 2021, 4:59 p.m. UTC | #2
On 5/21/2021 5:59 AM, Bagas Sanjaya wrote:
> On 21/05/21 05.13, Lénaïc Huard wrote:
>> The existing mechanism for scheduling background maintenance is done
>> through cron. On Linux systems managed by systemd, systemd provides an
>> alternative to schedule recurring tasks: systemd timers.
>>
>> The main motivations to implement systemd timers in addition to cron
>> are:
>> * cron is optional and Linux systems running systemd might not have it
>>    installed.
>> * The execution of `crontab -l` can tell us if cron is installed but not
>>    if the daemon is actually running.
>> * With systemd, each service is run in its own cgroup and its logs are
>>    tagged by the service inside journald. With cron, all scheduled tasks
>>    are running in the cron daemon cgroup and all the logs of the
>>    user-scheduled tasks are pretended to belong to the system cron
>>    service.
>>    Concretely, a user that doesn’t have access to the system logs won’t
>>    have access to the log of its own tasks scheduled by cron whereas he
>>    will have access to the log of its own tasks scheduled by systemd
>>    timer.
> 
> For gender neutrality, we can use he/she instead.

Singular "they" is better. Fully accurate and less awkward.

Thanks,
-Stolee
Johannes Schindelin May 22, 2021, 6:57 a.m. UTC | #3
Hi,

On Fri, 21 May 2021, Derrick Stolee wrote:

> On 5/21/2021 5:59 AM, Bagas Sanjaya wrote:
> > On 21/05/21 05.13, Lénaïc Huard wrote:
> >> The existing mechanism for scheduling background maintenance is done
> >> through cron. On Linux systems managed by systemd, systemd provides an
> >> alternative to schedule recurring tasks: systemd timers.
> >>
> >> The main motivations to implement systemd timers in addition to cron
> >> are:
> >> * cron is optional and Linux systems running systemd might not have it
> >>    installed.
> >> * The execution of `crontab -l` can tell us if cron is installed but not
> >>    if the daemon is actually running.
> >> * With systemd, each service is run in its own cgroup and its logs are
> >>    tagged by the service inside journald. With cron, all scheduled tasks
> >>    are running in the cron daemon cgroup and all the logs of the
> >>    user-scheduled tasks are pretended to belong to the system cron
> >>    service.
> >>    Concretely, a user that doesn’t have access to the system logs won’t
> >>    have access to the log of its own tasks scheduled by cron whereas he
> >>    will have access to the log of its own tasks scheduled by systemd
> >>    timer.
> >
> > For gender neutrality, we can use he/she instead.
>
> Singular "they" is better. Fully accurate and less awkward.

I agree. If the singular they was good enough for Shakespeare, it is good
enough for anyone. See for yourself:
http://itre.cis.upenn.edu/~myl/languagelog/archives/002748.html

Ciao,
Dscho
Felipe Contreras May 23, 2021, 6:36 p.m. UTC | #4
Johannes Schindelin wrote:
> On Fri, 21 May 2021, Derrick Stolee wrote:
> 
> > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote:
> > > On 21/05/21 05.13, Lénaïc Huard wrote:
> > >> The existing mechanism for scheduling background maintenance is done
> > >> through cron. On Linux systems managed by systemd, systemd provides an
> > >> alternative to schedule recurring tasks: systemd timers.
> > >>
> > >> The main motivations to implement systemd timers in addition to cron
> > >> are:
> > >> * cron is optional and Linux systems running systemd might not have it
> > >>    installed.
> > >> * The execution of `crontab -l` can tell us if cron is installed but not
> > >>    if the daemon is actually running.
> > >> * With systemd, each service is run in its own cgroup and its logs are
> > >>    tagged by the service inside journald. With cron, all scheduled tasks
> > >>    are running in the cron daemon cgroup and all the logs of the
> > >>    user-scheduled tasks are pretended to belong to the system cron
> > >>    service.
> > >>    Concretely, a user that doesn’t have access to the system logs won’t
> > >>    have access to the log of its own tasks scheduled by cron whereas he
> > >>    will have access to the log of its own tasks scheduled by systemd
> > >>    timer.
> > >
> > > For gender neutrality, we can use he/she instead.
> >
> > Singular "they" is better. Fully accurate and less awkward.
> 
> I agree.

I disagree.

> If the singular they was good enough for Shakespeare,

Shakespeare:

 1. Did not know gammar
 2. Invented words as we went along
 3. Was no writing prose

This is not the kind of English we wish to replicate:

  "This was the most unkindest cut of all."

> See for yourself:
> http://itre.cis.upenn.edu/~myl/languagelog/archives/002748.html

I do not see a single instance of a singular antecedent there.

Not that it matters, because unlike Shakespeare we are wriing classic
prose style. The styles could not be more different.


The singular they is a controversial topic[1][2], even among linguists.
This is a software project, we must not make decrees about proper use of
English language, especially when linguists themselves have not yet
fully decided.

If you want to use "they", go ahead, other people want to use "he/she".
The git project should steer cleer of value judgements that one is
_better_ than the other.

Not to mention that these kinds of promulgations invite the culture war.

Cheers.

[1] https://time.com/5748649/word-of-year-they-merriam-webster/
[2] https://www.theatlantic.com/culture/archive/2013/01/singular-their-affront-good-writing/319329/
brian m. carlson May 23, 2021, 11:27 p.m. UTC | #5
On 2021-05-23 at 18:36:10, Felipe Contreras wrote:
> Johannes Schindelin wrote:
> > On Fri, 21 May 2021, Derrick Stolee wrote:
> > 
> > > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote:
> > > > On 21/05/21 05.13, Lénaïc Huard wrote:
> > > >> The existing mechanism for scheduling background maintenance is done
> > > >> through cron. On Linux systems managed by systemd, systemd provides an
> > > >> alternative to schedule recurring tasks: systemd timers.
> > > >>
> > > >> The main motivations to implement systemd timers in addition to cron
> > > >> are:
> > > >> * cron is optional and Linux systems running systemd might not have it
> > > >>    installed.
> > > >> * The execution of `crontab -l` can tell us if cron is installed but not
> > > >>    if the daemon is actually running.
> > > >> * With systemd, each service is run in its own cgroup and its logs are
> > > >>    tagged by the service inside journald. With cron, all scheduled tasks
> > > >>    are running in the cron daemon cgroup and all the logs of the
> > > >>    user-scheduled tasks are pretended to belong to the system cron
> > > >>    service.
> > > >>    Concretely, a user that doesn’t have access to the system logs won’t
> > > >>    have access to the log of its own tasks scheduled by cron whereas he
> > > >>    will have access to the log of its own tasks scheduled by systemd
> > > >>    timer.
> > > >
> > > > For gender neutrality, we can use he/she instead.
> > >
> > > Singular "they" is better. Fully accurate and less awkward.
> > 
> > I agree.
> 
> I disagree.

I'm fully in support of singular "they".  It provides a useful pronoun
to use in this context, is widely understood and used, is less awkward
than "he/she," and is less sexist than the indefinite "he."

> > If the singular they was good enough for Shakespeare,
> 
> Shakespeare:
> 
>  1. Did not know gammar
>  2. Invented words as we went along
>  3. Was no writing prose

The point is that it has been used by native English speakers as part of
the language for over half a millennium and is widely used and
understood.  This usage is specified in Merriam Webster[0]:

  The use of they, their, them, and themselves as pronouns of indefinite
  gender and indefinite number is well established in speech and
  writing, even in literary and formal contexts.

Wiktionary notes[1] (references omitted):

  Usage of they as a singular pronoun began in the 1300s and has been
  common ever since, despite attempts by some grammarians, beginning in
  1795, to condemn it as a violation of traditional (Latinate)
  agreement rules.  Some other grammarians have countered that criticism
  since at least 1896.  Fowler's Modern English Usage (third edition)
  notes that it "is being left unaltered by copy editors" and is "not
  widely felt to lie in a prohibited zone."  Some authors compare use of
  singular they to widespread use of singular you instead of thou.

> The singular they is a controversial topic[1][2], even among linguists.
> This is a software project, we must not make decrees about proper use of
> English language, especially when linguists themselves have not yet
> fully decided.

Linguists fit roughly into two camps: prescriptive and descriptive.  The
former specify rules for people to use, and the latter document language
as it is actually used without forming a judgment.  While I am not a
linguist, I have a B.A. in English, and my views fit firmly into the
descriptivist camp.

Some prescriptivists think it is acceptable, and some do not.  But
descriptivists will rightly note that it is and has been commonly used
in English across countries, cultures, and contexts for an extended
period of time and is therefore generally accepted by most English
speakers as a normal part of the language.  Since we are writing text
for an English language audience who are mostly not linguists, we should
probably consider using the language that most people will use in this
context.

> If you want to use "they", go ahead, other people want to use "he/she".
> The git project should steer cleer of value judgements that one is
> _better_ than the other.

Any time we provide a suggestion in a code review, we are proposing that
we have an idea that may be better than the existing one.  It may or may
not actually be so, but we are proposing it in an effort to make the
code and documentation better.  No good-faith contributor would propose
a suggestion to make the project _worse_.

It's completely fine for a contributor to propose that they think an
idea is better provided that they do so in a respectful and considerate
way, which I think happened here.  As with all matters of opinion,
whether a thing is truly better or not is unknowable, and the best we
can do is to adopt an approach that seems to be the most widely accepted
and most provident.

In this case, given the fact that singular they is accepted in a wide
variety of contexts, including many literary and formal contexts, and
even the relatively stalwart Chicago "recognizes that such usage is
gaining [further] acceptance," I think it should be fine to use singular
they here.  You are, of course, free to feel differently.

[0] https://www.merriam-webster.com/dictionary/they
[1] https://en.wiktionary.org/wiki/they
Felipe Contreras May 24, 2021, 1:18 a.m. UTC | #6
brian m. carlson wrote:
> On 2021-05-23 at 18:36:10, Felipe Contreras wrote:
> > Johannes Schindelin wrote:
> > > On Fri, 21 May 2021, Derrick Stolee wrote:
> > > > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote:
> > > > > On 21/05/21 05.13, Lénaïc Huard wrote:
> > > > >> The existing mechanism for scheduling background maintenance is done
> > > > >> through cron. On Linux systems managed by systemd, systemd provides an
> > > > >> alternative to schedule recurring tasks: systemd timers.
> > > > >>
> > > > >> The main motivations to implement systemd timers in addition to cron
> > > > >> are:
> > > > >> * cron is optional and Linux systems running systemd might not have it
> > > > >>    installed.
> > > > >> * The execution of `crontab -l` can tell us if cron is installed but not
> > > > >>    if the daemon is actually running.
> > > > >> * With systemd, each service is run in its own cgroup and its logs are
> > > > >>    tagged by the service inside journald. With cron, all scheduled tasks
> > > > >>    are running in the cron daemon cgroup and all the logs of the
> > > > >>    user-scheduled tasks are pretended to belong to the system cron
> > > > >>    service.
> > > > >>    Concretely, a user that doesn’t have access to the system logs won’t
> > > > >>    have access to the log of its own tasks scheduled by cron whereas he
> > > > >>    will have access to the log of its own tasks scheduled by systemd
> > > > >>    timer.
> > > > >
> > > > > For gender neutrality, we can use he/she instead.
> > > >
> > > > Singular "they" is better. Fully accurate and less awkward.
> > > 
> > > I agree.
> > 
> > I disagree.
> 
> I'm fully in support of singular "they".

To each her/his own.

> It provides a useful pronoun to use in this context, is widely
> understood and used, is less awkward than "he/she," and is less sexist
> than the indefinite "he."

I disagree. But I wouldn't presume to dictate how other people speak.

If you like it, use it.

> > > If the singular they was good enough for Shakespeare,
> > 
> > Shakespeare:
> > 
> >  1. Did not know gammar
> >  2. Invented words as we went along
> >  3. Was no writing prose
> 
> The point is that it has been used by native English speakers as part of
> the language for over half a millennium and is widely used and
> understood.

A similar thing happens with the word "nucular" [1]; it is used by
native English speakers as part of the language for many decades and is
widely used and understood.

Does that mean it's a valid word? Maybe.

But does that make "nuclear" invalid? No.

You can use "nucular" if you want (many people do). I will use
"nuclear".

Both can be valid.

> This usage is specified in Merriam Webster[0]:

Merriam-Webster is not infallible.

But fine: let's say they are correct.

Where does it say "they" is *better*? Or worse: where does it say
"his/her" is discouraged?

> > The singular they is a controversial topic[1][2], even among linguists.
> > This is a software project, we must not make decrees about proper use of
> > English language, especially when linguists themselves have not yet
> > fully decided.
> 
> Linguists fit roughly into two camps: prescriptive and descriptive.

I am perfectly aware of the two camps, and I have written about it.

> While I am not a linguist, I have a B.A. in English, and my views fit
> firmly into the descriptivist camp.

If you are a descriptivist (as am I), then you must acknowledge that
people use "his/her" *today*.

As a descriptivist you shouldn't dare to _prescribe_ how people use words.

Therefore, if I use "his/her" (as many people do), you should not
prescribe otherwise.

> Since we are writing text for an English language audience who are
> mostly not linguists, we should probably consider using the language
> that most people will use in this context.

Consider, yes. Dictate? No.

And you don't know how *most* most people speak. Your guess is as good
as mine.

> It's completely fine for a contributor to propose that they think an
> idea is better provided that they do so in a respectful and considerate
> way, which I think happened here.

If you say you think **in your personal opinion** that A is better than
B, that's fine.

What was stated here was "A is better". So that's not what happened.

> I think it should be fine to use singular they here.  You are, of
> course, free to feel differently.

I do feel differently, but I would not presume to dictate that B is
better; I argue both A and B are fine.

 A. he/she
 B. they


To be perfectly clear; I'm not saying you shouldn't use B; I'm saying A
is fine.

Cheers.

[1] https://en.wikipedia.org/wiki/Nucular
Ævar Arnfjörð Bjarmason May 24, 2021, 7:03 a.m. UTC | #7
On Sun, May 23 2021, brian m. carlson wrote:

> [[PGP Signed Part:Undecided]]
> On 2021-05-23 at 18:36:10, Felipe Contreras wrote:
>> Johannes Schindelin wrote:
>> > On Fri, 21 May 2021, Derrick Stolee wrote:
>> > 
>> > > On 5/21/2021 5:59 AM, Bagas Sanjaya wrote:
>> > > > On 21/05/21 05.13, Lénaïc Huard wrote:
>> > > >> The existing mechanism for scheduling background maintenance is done
>> > > >> through cron. On Linux systems managed by systemd, systemd provides an
>> > > >> alternative to schedule recurring tasks: systemd timers.
>> > > >>
>> > > >> The main motivations to implement systemd timers in addition to cron
>> > > >> are:
>> > > >> * cron is optional and Linux systems running systemd might not have it
>> > > >>    installed.
>> > > >> * The execution of `crontab -l` can tell us if cron is installed but not
>> > > >>    if the daemon is actually running.
>> > > >> * With systemd, each service is run in its own cgroup and its logs are
>> > > >>    tagged by the service inside journald. With cron, all scheduled tasks
>> > > >>    are running in the cron daemon cgroup and all the logs of the
>> > > >>    user-scheduled tasks are pretended to belong to the system cron
>> > > >>    service.
>> > > >>    Concretely, a user that doesn’t have access to the system logs won’t
>> > > >>    have access to the log of its own tasks scheduled by cron whereas he
>> > > >>    will have access to the log of its own tasks scheduled by systemd
>> > > >>    timer.
>> > > >
>> > > > For gender neutrality, we can use he/she instead.
>> > >
>> > > Singular "they" is better. Fully accurate and less awkward.
>> > 
>> > I agree.
>> 
>> I disagree.
>
> I'm fully in support of singular "they".  It provides a useful pronoun
> to use in this context, is widely understood and used, is less awkward
> than "he/she," and is less sexist than the indefinite "he."

I think we should be the most concerned about the lack of inclusivity
and chilling effect in us being overly picky about the minute details of
commit message wording, long past the point of practical utility.

In this particular case the context is a discussion about "a user" on a
*nix system and what they do and don't have access to.

I think it's a particularly misguided distraction to argue about
he/she/they here, since the most accurate thing would really be "it".

At least on my *nix systems most users are system users, and don't map
to any particular human being, but I digress.

I would like to encourage people in this thread who are calling for a
change in wording here to consider whether this sort of discussion is a
good use of the ML's time, and the chilling effect of being overly picky
when many contributors are working in their second, third etc. language.

Personally I don't care whether someone submits a patch where their
commit message discusses an example of "he", "she", "they", "it" or
whatever. It's just meant as an example, and not some statement about
what the gender (or lack thereof) of such a user *should* be.

It's immediately obvious what the author meant in this case, and that
the particular wording is arbitrary. For the purposes of discussing the
contribution it matters whether it's unclear or ambiguous, which it's
not.
Junio C Hamano May 24, 2021, 3:51 p.m. UTC | #8
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Personally I don't care whether someone submits a patch where their
> commit message discusses an example of "he", "she", "they", "it" or
> whatever. It's just meant as an example, and not some statement about
> what the gender (or lack thereof) of such a user *should* be.
>
> It's immediately obvious what the author meant in this case, and that
> the particular wording is arbitrary. For the purposes of discussing the
> contribution it matters whether it's unclear or ambiguous, which it's
> not.

Nicely put.  Thanks.
Felipe Contreras May 24, 2021, 5:52 p.m. UTC | #9
Ævar Arnfjörð Bjarmason wrote:
> I would like to encourage people in this thread who are calling for a
> change in wording here to consider whether this sort of discussion is a
> good use of the ML's time, and the chilling effect of being overly picky
> when many contributors are working in their second, third etc. language.

I completely agree. However, there's a difference between calling for a
change, and expressing one's personal taste. The later can be useful
feedback, the former tramples the progress of a patch series.

> Personally I don't care whether someone submits a patch where their
> commit message discusses an example of "he", "she", "they", "it" or
> whatever. It's just meant as an example, and not some statement about
> what the gender (or lack thereof) of such a user *should* be.

Agreed. My only concern is readability, nonetheless a poorly readable
commit message is not a road-blocker.


What should not be debatable is that this is a software project, it
should not concern itself with linguistic debates. The proper use of
language is a matter for others to decide.

If a member of the community expresses her/his personal taste that Y is a
better word than X, that's fine. But to *demand* a word change is
something else.

Cheers.
Johannes Schindelin May 25, 2021, 1:50 a.m. UTC | #10
Hi,

On Tue, 25 May 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > Personally I don't care whether someone submits a patch where their
> > commit message discusses an example of "he", "she", "they", "it" or
> > whatever. It's just meant as an example, and not some statement about
> > what the gender (or lack thereof) of such a user *should* be.
> >
> > It's immediately obvious what the author meant in this case, and that
> > the particular wording is arbitrary. For the purposes of discussing the
> > contribution it matters whether it's unclear or ambiguous, which it's
> > not.
>
> Nicely put.  Thanks.

_Personally_ I don't care either. Because I am exactly in that group of
young, Caucasian male developers that are so highly overrepresented in our
community already. I will never have a problem thinking that I don't
belong here. I never had that problem.

And I believe that you, Ævar, are very much in the same boat. You will
never feel as if you don't belong in tech. You're Caucasian, male, and
like me, come with an abundance of confidence.

Now, let's go for a little thought experiment. Let's pretend for a moment
that we lacked that confidence. That we were trying to enter a community
with almost no male members at all. Where an email thread was going on
about inviting us to join, using no male pronouns, or putting them last.
And remember: no confidence, no representation. Now, would you dare
chiming in, offering myself as a target? I know I wouldn't. Yet that's
exactly the atmosphere we're fostering here.

What you say, matters. _How_ you say it, matters.

In other words, I think that the _personal_ opinions of everybody who
spoke up in this mail thread (you might have noticed that all of us are
male, you could even call it a "male thread") are not the problem we are
discussing. Personal opinions are kind of missing the point here. By a
mile. And then some.

The actual point is that we want to avoid giving the impression that
only people who feel included by the pronoun "he" are invited. That we
only really care about male users and developers, and pay only scant
tribute to the rest.

And yes, even "he/she", or "(s)he" would give that impression, by
emphasizing a priority order. And "they" simply would not do that. And if
it makes a few male readers slightly uncomfortable, it might present a
fine opportunity to exercise some empathy with those who feel
uncomfortable and excluded all the time.

Thank you,
Johannes
Felipe Contreras May 25, 2021, 11:13 a.m. UTC | #11
Johannes Schindelin wrote:

> Where an email thread was going on about inviting us to join, using no
> male pronouns, or putting them last.

This is totally and completely missing the point. Nobody objected to
using a female pronoun, nor using she/he.

I for one would have no problem using a female pronoun, and in fact I
often do [1].

This has absolutely nothing to do the issue at hand.

> I know I wouldn't. Yet that's exactly the atmosphere we're fostering
> here.

Except this is disconnected from reality.

 1. I know female colleagues who don't want to be treated more
    delicately than their male counterparts. And they certainly don't
    want unsolicited help, especially regarding hypothetical feelings
    they might have towards the use of a pronoun.

 2. On the other hand I do know people that lurk the mailing list and
    are afraid of expressing their opinions because of fear of reprisals
    in this PC-culture climate.

If anybody needs consideration I would side with the real, rather than
hypothetical, people.

[1] https://lore.kernel.org/git/60a66b11d6ffd_2448320885@natae.notmuch/
Ævar Arnfjörð Bjarmason May 26, 2021, 10:29 a.m. UTC | #12
On Tue, May 25 2021, Johannes Schindelin wrote:

> Hi,
>
> On Tue, 25 May 2021, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>> > Personally I don't care whether someone submits a patch where their
>> > commit message discusses an example of "he", "she", "they", "it" or
>> > whatever. It's just meant as an example, and not some statement about
>> > what the gender (or lack thereof) of such a user *should* be.
>> >
>> > It's immediately obvious what the author meant in this case, and that
>> > the particular wording is arbitrary. For the purposes of discussing the
>> > contribution it matters whether it's unclear or ambiguous, which it's
>> > not.
>>
>> Nicely put.  Thanks.
>
> _Personally_ I don't care either. Because I am exactly in that group of
> young, Caucasian male developers that are so highly overrepresented in our
> community already. I will never have a problem thinking that I don't
> belong here. I never had that problem.
>
> And I believe that you, Ævar, are very much in the same boat. You will
> never feel as if you don't belong in tech. You're Caucasian, male, and
> like me, come with an abundance of confidence.
>
> Now, let's go for a little thought experiment. Let's pretend for a moment
> that we lacked that confidence. That we were trying to enter a community
> with almost no male members at all. Where an email thread was going on
> about inviting us to join, using no male pronouns, or putting them last.
> And remember: no confidence, no representation. Now, would you dare
> chiming in, offering myself as a target? I know I wouldn't. Yet that's
> exactly the atmosphere we're fostering here.
>
> What you say, matters. _How_ you say it, matters.
>
> In other words, I think that the _personal_ opinions of everybody who
> spoke up in this mail thread (you might have noticed that all of us are
> male, you could even call it a "male thread") are not the problem we are
> discussing. Personal opinions are kind of missing the point here. By a
> mile. And then some.
>
> The actual point is that we want to avoid giving the impression that
> only people who feel included by the pronoun "he" are invited. That we
> only really care about male users and developers, and pay only scant
> tribute to the rest.
>
> And yes, even "he/she", or "(s)he" would give that impression, by
> emphasizing a priority order. And "they" simply would not do that. And if
> it makes a few male readers slightly uncomfortable, it might present a
> fine opportunity to exercise some empathy with those who feel
> uncomfortable and excluded all the time.
>
> Thank you,

I don't think it's helpful or in the spirit of our CoC to characterize
discussion in terms of the genders or nationalities of its participants.

I'm not accusing you of some CoC violation, just suggesting that it
makes more better conversation to take participants at their word and
assume good faith.

You can't say based on some superficial piece of information what a
project participant might be dealing with, e.g. perhaps they're anxious
about screwing up some trivial thing on a public ML, feel that they're
inexperienced and/or have some "impostor syndrome" etc.

The reason I chimed in on this thread was that I thought concern over
one such topic had started to negatively impact another. We've got a lot
of people trying to contribute who aren't comfortable contributing in
English, or whose proficiency doesn't extend to the latest linguistic
trends.

I'm suggesting that it's more helpful to leave certain things be than to
pounce on contributors about things that are ultimately not integral to
their work, and which can be readily understood.

E.g. if someone's clearly a speaker of a Slavic language and it shows in
their grammar I don't think we should be aiming to have them massage
their patch until it's indistinguishable from that of a native speaker
of English.

We should make sure we understand what's being said[1], but I think
anything past that point is starting to bring us negative value. At some
point it's good enough that we can understand the intent, and by
assuming good faith we're better off letting things like "he" v.s. "she"
v.s. "they" slide.

To not do so is to needlessly create a barrier to participation in this
project. I think the side discussion about Merriam Webster[2] somewhat
misses the mark here.

The question isn't whether what's being suggested would be a valid
sentence according to a dictionary, but whether e.g. someone who's
learned English from a commonly available textbook (I daresay most
"Beginner English" textbooks have more "he" and "she" examples than
"they") is going to inadvertently run afoul of other people's
preferences.

If they do it's more work for them (partially because they're a
non-native speaker), and ultimately more things we need to cover in
Documentation/SubmittingPatches etc. All of that's more barriers of
entry to project participation.

1. https://lore.kernel.org/git/87wns6u8pc.fsf@evledraar.gmail.com/
2. https://lore.kernel.org/git/YKrk4dEjEm6+48ji@camp.crustytoothpaste.net/
Felipe Contreras May 26, 2021, 4:05 p.m. UTC | #13
Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 25 2021, Johannes Schindelin wrote:

> > _Personally_ I don't care either. Because I am exactly in that group of
> > young, Caucasian male developers that are so highly overrepresented in our
> > community already. I will never have a problem thinking that I don't
> > belong here. I never had that problem.
> >
> > And I believe that you, Ævar, are very much in the same boat. You will
> > never feel as if you don't belong in tech. You're Caucasian, male, and
> > like me, come with an abundance of confidence.
> 
> I don't think it's helpful or in the spirit of our CoC to characterize
> discussion in terms of the genders or nationalities of its participants.

Not to mention that it's worryingly close to implying "if you are a straight
white cis male, your opinion doesn't matter".

I don't think the Git project should be assigning weight to the opinions
of community members based on gender, or race.
Jeff King May 27, 2021, 2:24 p.m. UTC | #14
On Wed, May 26, 2021 at 12:29:01PM +0200, Ævar Arnfjörð Bjarmason wrote:

> The reason I chimed in on this thread was that I thought concern over
> one such topic had started to negatively impact another. We've got a lot
> of people trying to contribute who aren't comfortable contributing in
> English, or whose proficiency doesn't extend to the latest linguistic
> trends.
> 
> I'm suggesting that it's more helpful to leave certain things be than to
> pounce on contributors about things that are ultimately not integral to
> their work, and which can be readily understood.

Yes, I want to express my support of this point, and not just for this
particular issue.

If you're a new contributor (or even an old one), it can be frustrating
to spend a lot of time working on and polishing up an improvement to the
software, to be met with feedback that mostly consists of "there's a
typo in your commit message". Whether that's true or not, or whether it
improves the commit message or not, it can feel like reviewers are
missing the point of the patch, which will discourage contributors.

As reviewers, I think we can do a few things to encourage people,
especially new contributors:

  - let little errors slide if they're not important. I think sometimes
    we get into a mentality that the commit message is baked into
    history, and thus needs to be revised and perfected. But commit
    messages are also just a conversation that's happening and being
    recorded. There will be hiccups, and polishing them forever has
    diminishing returns.

    (Of course this requires judgement; some commit messages really are
    just hard to follow, and I think you made that distinction with the
    phrase "make sure understand what's being said").

  - temper small corrections with positive feedback. Especially for new
    contributors, being told explicitly "yes, what you're trying to do
    here overall is welcome, and it all looks good except for this..."
    is much more encouraging than "this part is wrong". In the latter,
    they're left to guess if anybody even values the rest of the work at
    all.

  - likewise, I think it helps to give feedback on expectations for the
    process. Saying explicitly "this looks good; I think with this style
    change, it would be ready to get picked up" helps them understand
    that the fix will get them across the finish line (as opposed to
    just getting another round of fix requests).

I would even extend some of those into the code itself. Obviously we
don't want to lower the bar and take incorrect code, or even typos in
error messages. But I think we could stand to relax sometimes on issues
of style or "I would do it like this" (and at the very least, the
"temper small corrections" advice may apply).

I'm not really targeting anybody in particular in this thread (and
Lénaïc seems to have taken it all in stride in this case). It's more
just a reminder that it's easy to forget to do these kinds of things,
and keep this kind of perspective. I know I have not always done it
perfectly at times.

-Peff
Felipe Contreras May 27, 2021, 5:30 p.m. UTC | #15
Jeff King wrote:
> On Wed, May 26, 2021 at 12:29:01PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
> > The reason I chimed in on this thread was that I thought concern over
> > one such topic had started to negatively impact another. We've got a lot
> > of people trying to contribute who aren't comfortable contributing in
> > English, or whose proficiency doesn't extend to the latest linguistic
> > trends.
> > 
> > I'm suggesting that it's more helpful to leave certain things be than to
> > pounce on contributors about things that are ultimately not integral to
> > their work, and which can be readily understood.
> 
> Yes, I want to express my support of this point, and not just for this
> particular issue.
> 
> If you're a new contributor (or even an old one), it can be frustrating
> to spend a lot of time working on and polishing up an improvement to the
> software, to be met with feedback that mostly consists of "there's a
> typo in your commit message". Whether that's true or not, or whether it
> improves the commit message or not, it can feel like reviewers are
> missing the point of the patch, which will discourage contributors.
> 
> As reviewers, I think we can do a few things to encourage people,
> especially new contributors:
> 
>   - let little errors slide if they're not important. I think sometimes
>     we get into a mentality that the commit message is baked into
>     history, and thus needs to be revised and perfected. But commit
>     messages are also just a conversation that's happening and being
>     recorded. There will be hiccups, and polishing them forever has
>     diminishing returns.

Yes, polishing forever has diminishing returns, but that's not really
the hard problem here; the problem is when two people (or more) can't
agree on what "polishing" means. That's a more eternal forever.

Fortunately we do have a dictator, and he can make determinations to end
the eternal debate.

He can simply fix the commit message--or any other minor
details--himself.

Sure, that doesn't scale, and ideally we would want the patch
contributors to do these tasks themselves, and not burden the
maintainer. But if the task of herding the cats is taken forever, why
keep insisting? Just fix the commit message and move on.

> I would even extend some of those into the code itself. Obviously we
> don't want to lower the bar and take incorrect code, or even typos in
> error messages. But I think we could stand to relax sometimes on issues
> of style or "I would do it like this" (and at the very least, the
> "temper small corrections" advice may apply).

Plus code can be fixed later. If as a reviewer you really dislike one
aspect of a patch, you don't necessarily need to convince the author to
change it. You can propose a separate patch later on.


Sometimes good is good enough. Don't let perfect be the enemy of good.

Cheers.
Junio C Hamano May 27, 2021, 11:58 p.m. UTC | #16
Jeff King <peff@peff.net> writes:

> I'm not really targeting anybody in particular in this thread (and
> Lénaïc seems to have taken it all in stride in this case). It's more
> just a reminder that it's easy to forget to do these kinds of things,
> and keep this kind of perspective. I know I have not always done it
> perfectly at times.

Thanks.
Phillip Susi May 28, 2021, 2:44 p.m. UTC | #17
Jeff King writes:

>   - temper small corrections with positive feedback. Especially for new
>     contributors, being told explicitly "yes, what you're trying to do
>     here overall is welcome, and it all looks good except for this..."
>     is much more encouraging than "this part is wrong". In the latter,
>     they're left to guess if anybody even values the rest of the work at
>     all.

When I see only a minor nit like that I assume that by default, that
means there are no more serious issues, fix the typo, and resubmit.  If
a new contributor thinks that means they aren't welcome then I think
they have an expectation mismatch.

>   - likewise, I think it helps to give feedback on expectations for the
>     process. Saying explicitly "this looks good; I think with this style
>     change, it would be ready to get picked up" helps them understand
>     that the fix will get them across the finish line (as opposed to
>     just getting another round of fix requests).

That would be nice, but such comments can really only come from a
maintainer that plans on pushing the patch.  Most comments come from
bystanders and so nessesarily only consist of pointing out flaws, and
don't really need to be bloated with a bunch of fluff.  I prefer short,
and to the point communication.

> I would even extend some of those into the code itself. Obviously we
> don't want to lower the bar and take incorrect code, or even typos in
> error messages. But I think we could stand to relax sometimes on issues
> of style or "I would do it like this" (and at the very least, the
> "temper small corrections" advice may apply).

Isn't saying "I would do it like this" already a tempering statement?  I
take that as meaning there isn't anything neccesarily wrong with what
you did, but you might consider this advice.
Jeff King May 30, 2021, 9:58 p.m. UTC | #18
On Fri, May 28, 2021 at 10:44:25AM -0400, Phillip Susi wrote:

> >   - temper small corrections with positive feedback. Especially for new
> >     contributors, being told explicitly "yes, what you're trying to do
> >     here overall is welcome, and it all looks good except for this..."
> >     is much more encouraging than "this part is wrong". In the latter,
> >     they're left to guess if anybody even values the rest of the work at
> >     all.
> 
> When I see only a minor nit like that I assume that by default, that
> means there are no more serious issues, fix the typo, and resubmit.  If
> a new contributor thinks that means they aren't welcome then I think
> they have an expectation mismatch.

Sure, that may be your intent as a reviewer. My point was that the
recipient of the review does not always know that. Helping them
understand those expectations is part of welcoming them into the
community.

And even as somebody who has been part of the community for a long time
and understands that, it is still comforting to get actual positive
feedback, rather than an assumed "if I did not complain, it is OK".

> >   - likewise, I think it helps to give feedback on expectations for the
> >     process. Saying explicitly "this looks good; I think with this style
> >     change, it would be ready to get picked up" helps them understand
> >     that the fix will get them across the finish line (as opposed to
> >     just getting another round of fix requests).
> 
> That would be nice, but such comments can really only come from a
> maintainer that plans on pushing the patch.  Most comments come from
> bystanders and so nessesarily only consist of pointing out flaws, and
> don't really need to be bloated with a bunch of fluff.  I prefer short,
> and to the point communication.

Yes, I hesitated a little bit on this advice for that reason: it may be
even worse to mislead people about the state of a patch series, if you
the reviewer and the maintainer do not agree. IMHO it is still good for
reviewers to try to help manage newcomers through the process, but it
does make sense for them to be careful not to over-promise.

> > I would even extend some of those into the code itself. Obviously we
> > don't want to lower the bar and take incorrect code, or even typos in
> > error messages. But I think we could stand to relax sometimes on issues
> > of style or "I would do it like this" (and at the very least, the
> > "temper small corrections" advice may apply).
> 
> Isn't saying "I would do it like this" already a tempering statement?  I
> take that as meaning there isn't anything neccesarily wrong with what
> you did, but you might consider this advice.

Here I more meant cases where the two approaches have about the same
value. If your "I would do it like this" can be backed up with reasons
why it might be better (more efficient, more maintainable, and so on),
then that's probably helpful review to give. If it can't, then I'd
question whether it is worth the time to even bring up.

There's a big gray area, of course. Saying "it would be more readable
like this..." is sometimes a nuisance, and sometimes great advice. One
extra complication is that new contributors are often unsure how strong
the request is (e.g., if they disagree, do they _need_ to change it for
the patch to be accepted, or is it OK). I'll often qualify comments with
an explicit "I'm OK with doing it this way, but in case you really like this
other direction, I thought I'd mention it...".

Another complication with all of this advice is that sometimes new
contributors are in a mentoring relationship with one or more reviewers
(e.g., GSoC, Outreachy, or just people who have asked for help). And
there the cost/benefit tradeoff is different between frustrating a new
contributor and teaching them our style, norms, etc.

-Peff
diff mbox series

Patch

diff --git a/Documentation/git-maintenance.txt b/Documentation/git-maintenance.txt
index 7c4bb38a2f..50179e010f 100644
--- a/Documentation/git-maintenance.txt
+++ b/Documentation/git-maintenance.txt
@@ -181,16 +181,19 @@  OPTIONS
 	`maintenance.<task>.enabled` configured as `true` are considered.
 	See the 'TASKS' section for the list of accepted `<task>` values.
 
---scheduler=auto|crontab|launchctl|schtasks::
+--scheduler=auto|crontab|systemd-timer|launchctl|schtasks::
 	When combined with the `start` subcommand, specify the scheduler
 	to use to run the hourly, daily and weekly executions of
 	`git maintenance run`.
 	The possible values for `<scheduler>` depend on the system: `crontab`
-	is available on POSIX systems, `launchctl` is available on
-	MacOS and `schtasks` is available on Windows.
+	is available on POSIX systems, `systemd-timer` is available on Linux
+	systems, `launchctl` is available on MacOS and `schtasks` is available
+	on Windows.
 	By default or when `auto` is specified, a suitable scheduler for
 	the system is used. On MacOS, `launchctl` is used. On Windows,
-	`schtasks` is used. On all other systems, `crontab` is used.
+	`schtasks` is used. On Linux, `systemd-timer` is used if user systemd
+	timers are available, otherwise, `crontab` is used. On all other systems,
+	`crontab` is used.
 
 
 TROUBLESHOOTING
@@ -290,6 +293,52 @@  schedule to ensure you are executing the correct binaries in your
 schedule.
 
 
+BACKGROUND MAINTENANCE ON LINUX SYSTEMD SYSTEMS
+-----------------------------------------------
+
+While Linux supports `cron`, depending on the distribution, `cron` may
+be an optional package not necessarily installed. On modern Linux
+distributions, systemd timers are superseding it.
+
+If user systemd timers are available, they will be used as a replacement
+of `cron`.
+
+In this case, `git maintenance start` will create user systemd timer units
+and start the timers. The current list of user-scheduled tasks can be found
+by running `systemctl --user list-timers`. The timers written by `git
+maintenance start` are similar to this:
+
+-----------------------------------------------------------------------
+$ systemctl --user list-timers
+NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES
+Thu 2021-04-29 19:00:00 CEST 42min left    Thu 2021-04-29 18:00:11 CEST 17min ago  git-maintenance@hourly.timer git-maintenance@hourly.service
+Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago    git-maintenance@daily.timer  git-maintenance@daily.service
+Mon 2021-05-03 00:00:00 CEST 3 days left   Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service
+-----------------------------------------------------------------------
+
+One timer is registered for each `--schedule=<frequency>` option.
+
+The definition of the systemd units can be inspected in the following files:
+
+-----------------------------------------------------------------------
+~/.config/systemd/user/git-maintenance@.timer
+~/.config/systemd/user/git-maintenance@.service
+~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer
+~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer
+~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer
+-----------------------------------------------------------------------
+
+`git maintenance start` will overwrite these files and start the timer
+again with `systemctl --user`, so any customization should be done by
+creating a drop-in file, i.e. a `.conf` suffixed file in the
+`~/.config/systemd/user/git-maintenance@.service.d` directory.
+
+`git maintenance stop` will stop the user systemd timers and delete
+the above mentioned files.
+
+For more details, see `systemd.timer(5)`.
+
+
 BACKGROUND MAINTENANCE ON MACOS SYSTEMS
 ---------------------------------------
 
diff --git a/builtin/gc.c b/builtin/gc.c
index bf21cec059..d2432ee04f 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -2079,10 +2079,174 @@  static int crontab_update_schedule(enum enable_or_disable run_maintenance,
 	return result;
 }
 
+static int is_systemd_timer_available(void)
+{
+	const char *cmd = "systemctl";
+	int is_available;
+	static int cached_result = -1;
+#ifdef __linux__
+	struct child_process child = CHILD_PROCESS_INIT;
+#endif
+
+	if (cached_result != -1)
+		return cached_result;
+
+	if (get_schedule_cmd(&cmd, &is_available))
+		return is_available;
+
+#ifdef __linux__
+	strvec_split(&child.args, cmd);
+	strvec_pushl(&child.args, "--user", "list-timers", NULL);
+	child.no_stdin = 1;
+	child.no_stdout = 1;
+	child.no_stderr = 1;
+	child.silent_exec_failure = 1;
+
+	if (start_command(&child)) {
+		cached_result = 0;
+		return cached_result;
+	}
+	if (finish_command(&child)) {
+		cached_result = 0;
+		return cached_result;
+	}
+	cached_result = 1;
+	return cached_result;
+#else
+	return 0;
+#endif
+}
+
+static char *xdg_config_home_systemd(const char *filename)
+{
+	assert(filename);
+	return xdg_config_home("systemd/user/%s", filename);
+}
+
+static int systemd_timer_enable_unit(int enable,
+				     enum schedule_priority schedule)
+{
+	const char *cmd = "systemctl";
+	struct child_process child = CHILD_PROCESS_INIT;
+	const char *frequency = get_frequency(schedule);
+
+	get_schedule_cmd(&cmd, NULL);
+	strvec_split(&child.args, cmd);
+	strvec_pushl(&child.args, "--user", enable ? "enable" : "disable",
+		     "--now", NULL);
+	strvec_pushf(&child.args, "git-maintenance@%s.timer", frequency);
+
+	if (start_command(&child))
+		die(_("failed to run systemctl"));
+	return finish_command(&child);
+}
+
+static int systemd_timer_delete_unit_templates(void)
+{
+	char *filename = xdg_config_home_systemd("git-maintenance@.timer");
+	unlink(filename);
+	free(filename);
+
+	filename = xdg_config_home_systemd("git-maintenance@.service");
+	unlink(filename);
+	free(filename);
+
+	return 0;
+}
+
+static int systemd_timer_delete_units(void)
+{
+	return systemd_timer_enable_unit(DISABLE, SCHEDULE_HOURLY) ||
+	       systemd_timer_enable_unit(DISABLE, SCHEDULE_DAILY) ||
+	       systemd_timer_enable_unit(DISABLE, SCHEDULE_WEEKLY) ||
+	       systemd_timer_delete_unit_templates();
+}
+
+static int systemd_timer_write_unit_templates(const char *exec_path)
+{
+	char *filename;
+	FILE *file;
+	const char *unit;
+
+	filename = xdg_config_home_systemd("git-maintenance@.timer");
+	if (safe_create_leading_directories(filename))
+		die(_("failed to create directories for '%s'"), filename);
+	file = xfopen(filename, "w");
+	FREE_AND_NULL(filename);
+
+	unit = "# This file was created and is maintained by Git.\n"
+	       "# Any edits made in this file might be replaced in the future\n"
+	       "# by a Git command.\n"
+	       "\n"
+	       "[Unit]\n"
+	       "Description=Optimize Git repositories data\n"
+	       "\n"
+	       "[Timer]\n"
+	       "OnCalendar=%i\n"
+	       "Persistent=true\n"
+	       "\n"
+	       "[Install]\n"
+	       "WantedBy=timers.target\n";
+	fputs(unit, file);
+	fclose(file);
+
+	filename = xdg_config_home_systemd("git-maintenance@.service");
+	file = xfopen(filename, "w");
+	free(filename);
+
+	unit = "# This file was created and is maintained by Git.\n"
+	       "# Any edits made in this file might be replaced in the future\n"
+	       "# by a Git command.\n"
+	       "\n"
+	       "[Unit]\n"
+	       "Description=Optimize Git repositories data\n"
+	       "\n"
+	       "[Service]\n"
+	       "Type=oneshot\n"
+	       "ExecStart=\"%s/git\" --exec-path=\"%s\" for-each-repo --config=maintenance.repo maintenance run --schedule=%%i\n"
+	       "LockPersonality=yes\n"
+	       "MemoryDenyWriteExecute=yes\n"
+	       "NoNewPrivileges=yes\n"
+	       "RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6\n"
+	       "RestrictNamespaces=yes\n"
+	       "RestrictRealtime=yes\n"
+	       "RestrictSUIDSGID=yes\n"
+	       "SystemCallArchitectures=native\n"
+	       "SystemCallFilter=@system-service\n";
+	fprintf(file, unit, exec_path, exec_path);
+	fclose(file);
+
+	return 0;
+}
+
+static int systemd_timer_setup_units(void)
+{
+	const char *exec_path = git_exec_path();
+
+	return systemd_timer_write_unit_templates(exec_path) ||
+	       systemd_timer_enable_unit(ENABLE, SCHEDULE_HOURLY) ||
+	       systemd_timer_enable_unit(ENABLE, SCHEDULE_DAILY) ||
+	       systemd_timer_enable_unit(ENABLE, SCHEDULE_WEEKLY);
+}
+
+static int systemd_timer_update_schedule(enum enable_or_disable run_maintenance,
+					 int fd)
+{
+	switch (run_maintenance) {
+	case ENABLE:
+		return systemd_timer_setup_units();
+	case DISABLE:
+		return systemd_timer_delete_units();
+	default:
+		BUG("invalid enable_or_disable value");
+	}
+}
+
 enum scheduler {
 	SCHEDULER_INVALID = -1,
 	SCHEDULER_AUTO,
 	SCHEDULER_CRON,
+	SCHEDULER_SYSTEMD,
 	SCHEDULER_LAUNCHCTL,
 	SCHEDULER_SCHTASKS,
 };
@@ -2097,6 +2261,11 @@  static const struct {
 		.is_available = is_crontab_available,
 		.update_schedule = crontab_update_schedule,
 	},
+	[SCHEDULER_SYSTEMD] = {
+		.name = "systemctl",
+		.is_available = is_systemd_timer_available,
+		.update_schedule = systemd_timer_update_schedule,
+	},
 	[SCHEDULER_LAUNCHCTL] = {
 		.name = "launchctl",
 		.is_available = is_launchctl_available,
@@ -2117,6 +2286,9 @@  static enum scheduler parse_scheduler(const char *value)
 		return SCHEDULER_AUTO;
 	else if (!strcasecmp(value, "cron") || !strcasecmp(value, "crontab"))
 		return SCHEDULER_CRON;
+	else if (!strcasecmp(value, "systemd") ||
+		 !strcasecmp(value, "systemd-timer"))
+		return SCHEDULER_SYSTEMD;
 	else if (!strcasecmp(value, "launchctl"))
 		return SCHEDULER_LAUNCHCTL;
 	else if (!strcasecmp(value, "schtasks"))
@@ -2155,6 +2327,15 @@  static void resolve_auto_scheduler(enum scheduler *scheduler)
 	*scheduler = SCHEDULER_SCHTASKS;
 	return;
 
+#elif defined(__linux__)
+	if (is_systemd_timer_available())
+		*scheduler = SCHEDULER_SYSTEMD;
+	else if (is_crontab_available())
+		*scheduler = SCHEDULER_CRON;
+	else
+		die(_("neither systemd timers nor crontab are available"));
+	return;
+
 #else
 	*scheduler = SCHEDULER_CRON;
 	return;
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 9eac260307..c8a6f19ebc 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -20,6 +20,18 @@  test_xmllint () {
 	fi
 }
 
+test_lazy_prereq SYSTEMD_ANALYZE '
+	systemd-analyze --help >out &&
+	grep verify out
+'
+
+test_systemd_analyze_verify () {
+	if test_have_prereq SYSTEMD_ANALYZE
+	then
+		systemd-analyze verify "$@"
+	fi
+}
+
 test_expect_success 'help text' '
 	test_expect_code 129 git maintenance -h 2>err &&
 	test_i18ngrep "usage: git maintenance <subcommand>" err &&
@@ -628,14 +640,54 @@  test_expect_success 'start and stop Windows maintenance' '
 	test_cmp expect args
 '
 
+test_expect_success 'start and stop Linux/systemd maintenance' '
+	write_script print-args <<-\EOF &&
+	printf "%s\n" "$*" >>args
+	EOF
+
+	XDG_CONFIG_HOME="$PWD" &&
+	export XDG_CONFIG_HOME &&
+	rm -f args &&
+	GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args" git maintenance start --scheduler=systemd-timer &&
+
+	# start registers the repo
+	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
+
+	test_systemd_analyze_verify "systemd/user/git-maintenance@.service" &&
+
+	printf -- "--user enable --now git-maintenance@%s.timer\n" hourly daily weekly >expect &&
+	test_cmp expect args &&
+
+	rm -f args &&
+	GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args" git maintenance stop &&
+
+	# stop does not unregister the repo
+	git config --get --global --fixed-value maintenance.repo "$(pwd)" &&
+
+	test_path_is_missing "systemd/user/git-maintenance@.timer" &&
+	test_path_is_missing "systemd/user/git-maintenance@.service" &&
+
+	printf -- "--user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect &&
+	test_cmp expect args
+'
+
 test_expect_success 'start and stop when several schedulers are available' '
 	write_script print-args <<-\EOF &&
 	printf "%s\n" "$*" | sed "s:gui/[0-9][0-9]*:gui/[UID]:; s:\(schtasks /create .* /xml\).*:\1:;" >>args
 	EOF
 
 	rm -f args &&
-	GIT_TEST_MAINT_SCHEDULER="launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=launchctl &&
-	rm -f expect &&
+	GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args systemctl,launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=systemd-timer &&
+	printf -- "systemctl --user enable --now git-maintenance@%s.timer\n" hourly daily weekly >expect &&
+	printf "launchctl bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \
+		hourly daily weekly >>expect &&
+	printf "schtasks /delete /tn Git Maintenance (%s) /f\n" \
+		hourly daily weekly >>expect &&
+	test_cmp expect args &&
+
+	rm -f args &&
+	GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args systemctl,launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=launchctl &&
+	printf -- "systemctl --user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect &&
 	for frequency in hourly daily weekly
 	do
 		PLIST="$pfx/Library/LaunchAgents/org.git-scm.git.$frequency.plist" &&
@@ -647,17 +699,19 @@  test_expect_success 'start and stop when several schedulers are available' '
 	test_cmp expect args &&
 
 	rm -f args &&
-	GIT_TEST_MAINT_SCHEDULER="launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=schtasks &&
+	GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args systemctl,launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance start --scheduler=schtasks &&
+	printf -- "systemctl --user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect &&
 	printf "launchctl bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \
-		hourly daily weekly >expect &&
+		hourly daily weekly >>expect &&
 	printf "schtasks /create /tn Git Maintenance (%s) /f /xml\n" \
 		hourly daily weekly >>expect &&
 	test_cmp expect args &&
 
 	rm -f args &&
-	GIT_TEST_MAINT_SCHEDULER="launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance stop &&
+	GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args systemctl,launchctl:./print-args launchctl,schtasks:./print-args schtasks" git maintenance stop &&
+	printf -- "systemctl --user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect &&
 	printf "launchctl bootout gui/[UID] $pfx/Library/LaunchAgents/org.git-scm.git.%s.plist\n" \
-		hourly daily weekly >expect &&
+		hourly daily weekly >>expect &&
 	printf "schtasks /delete /tn Git Maintenance (%s) /f\n" \
 		hourly daily weekly >>expect &&
 	test_cmp expect args