t7900 fails with recent debian systemd?

t7900 fails with recent debian systemd?

[Jeff King]

I noticed t7900 failing today. The failure looks like this:

  $ ./t7900-maintenance.sh -v -i -x
  [...]
  + systemd-analyze verify systemd/user/git-maintenance@hourly.service
  Unit git-maintenance@hourly.service not found.
  error: last command exited with $?=1
  not ok 36 - start and stop Linux/systemd maintenance

The problem started after upgrading my Debian unstable system to the
systemd 255~rc4-2 deb. Downgrading back to 254.5-1 makes the test pass
again.

I'm sure it's something silly with finding paths in XDG_CONFIG_HOME or
something like that. I haven't dug further, but I thought I'd post this
to save somebody else going through the same initial debugging. (And of
course any wisdom or further debugging is greatly appreciated).

-Peff

Re: t7900 fails with recent debian systemd?

[Jeff King]

On Wed, Dec 06, 2023 at 05:31:45PM -0500, Jeff King wrote:

> I noticed t7900 failing today. The failure looks like this:
> 
>   $ ./t7900-maintenance.sh -v -i -x
>   [...]
>   + systemd-analyze verify systemd/user/git-maintenance@hourly.service
>   Unit git-maintenance@hourly.service not found.
>   error: last command exited with $?=1
>   not ok 36 - start and stop Linux/systemd maintenance
> 
> The problem started after upgrading my Debian unstable system to the
> systemd 255~rc4-2 deb. Downgrading back to 254.5-1 makes the test pass
> again.
> 
> I'm sure it's something silly with finding paths in XDG_CONFIG_HOME or
> something like that. I haven't dug further, but I thought I'd post this
> to save somebody else going through the same initial debugging. (And of
> course any wisdom or further debugging is greatly appreciated).

After stracing, it is indeed looking for:

  trash directory.t7900-maintenance/systemd/user/git-maintenance@hourly.service

but that file doesn't exist. We installed git-maintenance@hourly.timer,
and git-maintenance@.service. Is the latter supposed to be a wildcard of
some kind? Maybe the rules changed. I don't really know anything about
systemd.

-Peff

Re: t7900 fails with recent debian systemd?

[Eric Sunshine]

On Wed, Dec 6, 2023 at 5:36 PM Jeff King <peff@peff.net> wrote:
> After stracing, it is indeed looking for:
>
>   trash directory.t7900-maintenance/systemd/user/git-maintenance@hourly.service
>
> but that file doesn't exist. We installed git-maintenance@hourly.timer,
> and git-maintenance@.service. Is the latter supposed to be a wildcard of
> some kind? Maybe the rules changed. I don't really know anything about
> systemd.

Apparently, that's intentional. From builtin/gc.c:

    /*
     * No matter the schedule, we use the same service and can make
     * use of the templating system. When installing
     * git-maintenance@<schedule>.timer, systemd will notice that
     * git-maintenance@.service exists as a template and will use this
     * file and insert the <schedule> into the template at the
     * position of "%i".
     */
    static int systemd_timer_write_service_template(const char *exec_path)
    {
        char *local_service_name = xstrfmt(SYSTEMD_UNIT_FORMAT, "", "service");

I'm not sure why the comment is talking about "%i", though.

Re: t7900 fails with recent debian systemd?

[Jeff King]

On Wed, Dec 06, 2023 at 05:40:59PM -0500, Eric Sunshine wrote:

> On Wed, Dec 6, 2023 at 5:36 PM Jeff King <peff@peff.net> wrote:
> > After stracing, it is indeed looking for:
> >
> >   trash directory.t7900-maintenance/systemd/user/git-maintenance@hourly.service
> >
> > but that file doesn't exist. We installed git-maintenance@hourly.timer,
> > and git-maintenance@.service. Is the latter supposed to be a wildcard of
> > some kind? Maybe the rules changed. I don't really know anything about
> > systemd.
> 
> Apparently, that's intentional. From builtin/gc.c:
> 
>     /*
>      * No matter the schedule, we use the same service and can make
>      * use of the templating system. When installing
>      * git-maintenance@<schedule>.timer, systemd will notice that
>      * git-maintenance@.service exists as a template and will use this
>      * file and insert the <schedule> into the template at the
>      * position of "%i".
>      */
>     static int systemd_timer_write_service_template(const char *exec_path)
>     {
>         char *local_service_name = xstrfmt(SYSTEMD_UNIT_FORMAT, "", "service");

OK, that makes sense, and this is indeed the way to do template files in
systemd.

> I'm not sure why the comment is talking about "%i", though.

The "%i" replacement is done on the contents of the template file
itself. So inside git-maintenance@.service, the ExecStart line specifies
that we should run "git maintenance run --schedule=%i".

This looks like a regression in systemd itself. I was able to bisect and
I left a comment there:

  https://github.com/systemd/systemd/pull/30172#issuecomment-1844699620

I don't really see a way to work around it within our test suite, short
of just skipping the "systemd-analyze verify" calls entirely. Hopefully
my analysis is right and they will fix it soon, and we can consider it
"not our problem" on this end. :)

-Peff