Hi,
systemd itself already uses them in those sections without problems so they should definitely work:
systemd-zram-setup@.service:After=dev-%i.device
systemd-journald@.service:Requires=systemd-journald@%i.socket systemd-journald-varlink@%i.socket
systemd-journald@.service:After=systemd-journald@%i.socket systemd-journald-varlink@%i.socket
serial-getty@.service:After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service getty-pre.target
systemd-journald-sync@.service:Requires=systemd-journald@%i.socket systemd-journald-varlink@%i.socket
systemd-journald-sync@.service:After=systemd-journald@%i.socket systemd-journald-varlink@%i.socket
user@.service:After=systemd-logind.service user-runtime-dir@%i.service dbus.service systemd-oomd.service
systemd-fsck@.service:After=%i.device systemd-fsck-root.service local-fs-pre.target
quotaon@.service:After=systemd-quotacheck@%i.service %i.mount
systemd-pcrfs@.service:After=%i.mount tpm2.target systemd-pcrfs-root.service
systemd-quotacheck@.service:After=%i.mount
systemd-growfs@.service:After=systemd-repart.service %i.mount
Maybe you did not account for some of the escaping systemd does (esp. slashes)? It could also be that you are using a very old systemd version though I think this has been possible for ages if not forever.
Cheers, Nils
On Thu, Jan 16, 2025 at 1:30 PM Thomas HUMMEL <thomas.hummel@xxxxxxxxxx> wrote:
Hello,
Is the %i (or %I) specifier supposed to be valid for a template service
unit for the Require= and After= directives ?
It does not seem so in my tests
Documentation states:
"you may use the special "%i" specifier in many of the configuration
options" but don't seem to detail which one exactly.
It also states:
"The following specifiers are interpreted in the Install section: %a,
%b, %B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %%"
But I think some are valid in (some) directives of the [Unit] or
[Service] section.
My use case would be to express a dynamic activation and order
dependency on a device name known only at boot time.
Thanks for your help
--
Thomas HUMMEL
HPC Group
Institut PASTEUR
Paris, FRANCE
