[systemd] Instanziierte Services mit trennzeichen

13/07/2015 - 16:46 von Marc Haber | Report spam
Hallo,

gegeben ist ein foo@.service:
|[Service]
|ExecStart=/usr/sbin/foo -f foo-%i.conf

wenn ich den Service als foo@bar starte, entsteht die Kommandozeile
/usr/sbin/foo -f foo-bar.conf. So weit klar.

Was psasiert wenn ich den service als foo@ starte? Wird dann
/usr/sbin/foo -f foo-.conf aufgerufen? Bekomme ich irgendwie hin, dass
in diesem fall nur /usr/sbin/foo -f foo.conf entsteht?

Oder dupliziere ich foo@.service nach foo.service:
|[Service]
|ExecStart=/usr/sbin/foo -f foo.conf
und lebe damit, dass ich foo und foo@bar starten muss und dass das
service-file im Prinzip zweimal da steht?

Grüße
Marc
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
 

Lesen sie die antworten

#1 Martin Vaeth
13/07/2015 - 19:04 | Warnen spam
Marc Haber <mh+ schrieb:
gegeben ist ein :
|[Service]
|ExecStart=/usr/sbin/foo -f foo-%i.conf

[...] Bekomme ich irgendwie hin, dass
in diesem fall nur /usr/sbin/foo -f foo.conf entsteht?



Auch in diesem Fall wohl nur über Benutzung einer Shell
oder geeignetes Schreiben des Kommandos /usr/sbin/foo.
Daran krankt halt die gesamte unit-Idee schon von Anfang an:

Die Shell wird als vermeintlich "böse" verteufelt, und dadurch
ist man halt auf die (grundsàtzlich nie ausreichenden)
Möglichkeiten einer armen-Leute-Heuristik beschrànkt.

Klar, die Syntax wird mit jeder neuen systemd-Version mehr
aufgebohrt, und in ein paar Jahren werden die Units
vielleicht viele oder gar alle Möglichkeiten einer derzeitigen
Shell bieten. (Oder man verfàllt wie bei bei policykit auf
die Idiotie, einen Javascript-Interpreter einzubauen.)

Was daran besser als die Benutzung der Shell sein soll,
zu deren Vermeidung man die ganzen derzeitigen Restriktionen
hinnehmen soll...

Ähnliche fragen