[systemd-devel] Multiple template parameters for one service

[Lennart Poettering]

On Sat, 28.06.14 18:15, Moviuro (moviuro at gmail.com) wrote:

> Hi all,
> 
> I am at the moment trying to clean up my units to write some simple ones that 
> I just have to link without hardcoding anything in them but am stuck at this 
> issue: what to do if my unit requires multiple parameters?
> 
> E.g. Using unison to sync files, the different variables I have to use are: 
> local user and profile file (an optional variable would be the server). It is 
> at the moment not possible to write a unit file that would understand so many 
> things with just a simple '@'.
> I could use an extra configuration file in /etc/systemd/system every time I 
> want to use unison, but it's not really nice and clean (one file per unison 
> profile...).
> Some people would object that I can have a bash script do the job of 
> translating what is behind the '@' into my many arguments: not really nice 
> either.
> 
> An idea would be to use units with many '@' or have systemd interpret the 
> string between '@' and '.service' as '@'-separated values (e.g. 
> unison at local_user@profile.service).
> 
> The feature could also help by including some optional arguments (e.g. the 
> server information in unison is not necessary for it to work but could help if 
> I use a service to check if the server is online beforehand: 
> unison at local_user@profile at server.service).

Hummm... So far the instancing was strictly one-dimensional from
systemd's PoV. And I think I would prefer it like that, since it makes
so many things easier. I mean, as you notice, one can always parse this
from shell or so, if you want, so we can actually get away with not
supporting anything more complex with systemd.

(Note that specifically using this for running things as unpriviliged
normal users: I'd encourage you not to do this with system-level
services, but instead run this as user services, from the systemd user
instance. Of course, the work on thta isn't complete yet, but it
definitely sounds like the more correct option for the long run).

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat