[systemd-devel] Multiple template parameters for one service

[Mantas Mikulėnas]

On Mon, Jun 30, 2014 at 1:38 PM, Lennart Poettering
<lennart at poettering.net> wrote:
>
> 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).

User services work quite well for such things already, only the X11
and DBus session-bus access is still problematic. Should be fine for
Unison.

-- 
Mantas Mikulėnas <grawity at gmail.com>