[systemd-devel] %j and symbolic links to unit files.

[Carlo Wood]

If I have a template unit foo at .service
and I have a symlink in /etc/systemd/system/
foo-bar at .service -> /usr/lib/systemd/system/foo at .service

1) is adding a symbolic link like this supported?
2) is using %j inside foo at .service supported in this case
(aka, allowed and it should work)?

If then I start this alias with
sudo systemctl start foo-bar at instance.service

3) what should %j expand to? (assuming 'yes' to 2) above).

What I expect:

1) yes (I see symbolic links being used all over the place,
so why not for a template unit where one uses an extra `-bar`?)

2) yes (seems kinda pointless not to (want to) support it)

3) it should always expand to 'bar' if the unit is started
   with `sudo systemctl start foo-bar at instance.service`.

Carlo Wood

PS
[ In case someone wants to answer 'no' somewhere. The rationale
of why this should work (why I need it) is as follows:

/usr/lib/systemd/system/foo at .service is part of a package
and may be updated when that packages is upgraded. It uses
%j and %i where both values are user supplied: if a user
needs some value of %j to work, they need to add a symbolic
link in /etc/systemd/system/. If they make a copy instead
of using a symbolic link, then that file will not be updated
if the package is upgraded and the use of %j is pointless
(might as well make that copy and then change it to use
'bar' everywhere).
The package maintainer loses control over correct upgrades
because they do not manage the copied files; other files of
the same package are upgraded, but the copied files are not,
leading to errors. The package maintainer also can't add
a copy of foo at .service for every value of %j because 1) they
don't know what value of %j the user needs, and 2) in that case
the use of %j would be pointless (might as well replace the %j
with whatever this copy is called). The ONLY reason that the
use of %j seems useful is when it is used in combination with
symbolic links. ]