threads / discuss / 60589

t7900 fails with recent debian systemd?

Subject: t7900 fails with recent debian systemd?

## tl;dr

4 messages between Dec 6, 2023 and Dec 7, 2023.

replies: 3people: 2as markdown or json

Jeff King· Dec 6, 2023, 22:31 UTC · lore
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
Jeff King· Dec 6, 2023, 22:36 UTC · re: Jeff King · lore

Re: t7900 fails with recent debian systemd?

On Wed, Dec 06, 2023 at 05:31:45PM -0500, Jeff King wrote:
Show 17 quoted lines
> 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
Eric Sunshine· Dec 6, 2023, 22:40 UTC · re: Jeff King · lore

Re: t7900 fails with recent debian systemd?

On Wed, Dec 6, 2023 at 5:36 PM Jeff King <peff@peff.net> wrote:
Show 8 quoted lines
> 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.
Jeff King· Dec 7, 2023, 06:27 UTC · re: Eric Sunshine · lore

Re: t7900 fails with recent debian systemd?

On Wed, Dec 06, 2023 at 05:40:59PM -0500, Eric Sunshine wrote:
Show 23 quoted lines
> 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

← back to recent threads