<div dir="ltr"><div>Apologies.</div><div>Systemd (<a href="https://github.com/systemd/systemd/blob/f2af682cd6308f9b26035b83063e6aa8593e468c/docs/CONTRIBUTING.md">https://github.com/systemd/systemd/blob/f2af682cd6308f9b26035b83063e6aa8593e468c/docs/CONTRIBUTING.md</a>) says take the bug to Debian.<br>Debian (<a href="https://www.debian.org/Bugs/Reporting">https://www.debian.org/Bugs/Reporting</a>) says don't file bugs upstream.<br><br></div><div>Using Systemd version 251.3-1~bpo11+1 produces identical results to those previously described. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 18 Jan 2023 at 17:30, Michael Biebl <<a href="mailto:biebl@debian.org">biebl@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
Am 18.01.23 um 18:21 schrieb Mike:<br>
> Package: systemd<br>
> Version: 247.3-7+deb11u1<br>
> Severity: normal<br>
> X-Debbugs-Cc: <a href="http://mike.shaw.nz" rel="noreferrer" target="_blank">mike.shaw.nz</a>+<a href="mailto:debian@gmail.com" target="_blank">debian@gmail.com</a><br>
> <br>
> Dear Maintainer,<br>
> <br>
> Under certain circumstances I'm seeing inconsistent values for the %j specifier used in service and drop-in units.<br>
> To reproduce:<br>
> <br>
> Create a systemd unit /lib/systemd/system/foo@.service as:<br>
> <br>
>      [Unit]<br>
>      Description=good old foo<br>
> <br>
>      [Service]<br>
>      Type=oneshot<br>
>      ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (foo@.service))"<br>
> <br>
> Create a drop-in unit /etc/systemd/system/foo@.service.d/additional.conf as:<br>
> <br>
>      [Service]<br>
>      ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (additional.conf))"<br>
> <br>
> Reload the systemd units and run systemctl cat foo@.service.  The output shows the drop-in being correctly incorporated:<br>
> <br>
>      # /lib/systemd/system/foo@.service<br>
>      [Unit]<br>
>      Description=good old foo<br>
> <br>
>      [Service]<br>
>      Type=oneshot<br>
>      ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (foo@.service))"<br>
> <br>
>      # /etc/systemd/system/foo@.service.d/additional.conf<br>
>      [Service]<br>
>      ExecStart=/bin/env echo "%%i=[%i]   %%j=[%j] (from %n (additional.conf))"<br>
> <br>
> Now create a symlink which contains a %j specifier:<br>
> <br>
>      sudo ln -sv /lib/systemd/system/foo@.service /etc/systemd/system/foo-bar@.service<br>
> <br>
> Reload the systemd units and run systemctl cat foo-bar@.service.  The output is identical to that of systemctl cat foo@.service<br>
> Now start the service with a %i specifer:<br>
> <br>
>      systemctl start foo-bar@baz.service<br>
> <br>
> The output is:<br>
> <br>
>      ● foo@baz.service - good old foo<br>
>           Loaded: loaded (/lib/systemd/system/foo@.service; static)<br>
>           Drop-In: /etc/systemd/system/foo@.service.d<br>
>                   └─additional.conf<br>
>           Active: inactive (dead)<br>
> <br>
>      Nov 01 12:10:31 Intel-NUC systemd[1]: Starting good old foo...<br>
>      Nov 01 12:10:31 Intel-NUC env[56108]: %i=[baz]   %j=[bar] (from foo-bar@baz.service (foo@.service))<br>
>      Nov 01 12:10:31 Intel-NUC env[56109]: %i=[baz]   %j=[foo] (from foo@baz.service (additional.conf))<br>
>      Nov 01 12:10:31 Intel-NUC systemd[1]: foo@baz.service: Succeeded.<br>
>      Nov 01 12:10:31 Intel-NUC systemd[1]: Finished good old foo.<br>
> <br>
> This shows that - in a single invocation - the value for %i is constant but the value for %j changes from 'bar' to 'foo'.  I would have expected the value of %j to be 'bar' throughout.  This may not be a bug, but - IMHO - this changing of values is unintuitive and I have been unable to find documentation that states the expected behaviour in this situation.  Happy to accept that I have confused/abused systemd with my custom /etc/systemd/system/foo-bar@.service symlink.<br>
> <br>
<br>
Ideally, such issues should be tested with the latest version of systemd <br>
(or at least v251) and then reported upstream.<br>
<br>
</blockquote></div>