On Mon, Jun 30, 2014 at 1:38 PM, Lennart Poettering <lenn...@poettering.net> wrote: > > On Sat, 28.06.14 18:15, Moviuro (movi...@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@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@local_user@profile@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 <graw...@gmail.com> _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
