# t7900 fails with recent debian systemd? 4 messages from 2023-12-06 to 2023-12-07. Participants: Jeff King, Eric Sunshine. Thread: https://gitlist.dev/t/60589 ## Jeff King, 2023-12-06 22:31 Subject: t7900 fails with recent debian systemd? Message-ID: <20231206223145.GA638844@coredump.intra.peff.net> URL: https://gitlist.dev/e/20231206223145.GA638844%40coredump.intra.peff.net ``` 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, 2023-12-06 22:36 Subject: Re: t7900 fails with recent debian systemd? Message-ID: <20231206223612.GA650770@coredump.intra.peff.net> URL: https://gitlist.dev/e/20231206223612.GA650770%40coredump.intra.peff.net In-Reply-To: <20231206223145.GA638844@coredump.intra.peff.net> ``` 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 ``` ## Eric Sunshine, 2023-12-06 22:40 Subject: Re: t7900 fails with recent debian systemd? Message-ID: URL: https://gitlist.dev/e/CAPig%2BcT-vCraf2tfA3t3Rh6mLNTr0rB5mApmz0vu2MCRvssaVw%40mail.gmail.com In-Reply-To: <20231206223612.GA650770@coredump.intra.peff.net> ``` On Wed, Dec 6, 2023 at 5:36 PM Jeff King 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@.timer, systemd will notice that * git-maintenance@.service exists as a template and will use this * file and insert the 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, 2023-12-07 06:27 Subject: Re: t7900 fails with recent debian systemd? Message-ID: <20231207062752.GA777253@coredump.intra.peff.net> URL: https://gitlist.dev/e/20231207062752.GA777253%40coredump.intra.peff.net In-Reply-To: ``` On Wed, Dec 06, 2023 at 05:40:59PM -0500, Eric Sunshine wrote: > On Wed, Dec 6, 2023 at 5:36 PM Jeff King 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@.timer, systemd will notice that > * git-maintenance@.service exists as a template and will use this > * file and insert the 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 ```