systemctl - customizing unit files

pibi

New Member
Hallo zusammen

Hinweis: Diese Frage habe ich auch hier gestellt, leider bisher erfolglos.

Mein System: openSuSI 13.1

Nach meinem anfaenglichen Widerstand gegen den neuen systemctl versuche ich, mich mit diesem Teil anzufreunden. Die Gelegenheit ist nun da;-)

Ich habe den bacula-Client installiert, aber er startet nicht. Die Fehlermeldung ist eindeutig:
Code:
Failed to issue method call: Unit syslog.target failed to load: No such file or directory.
Soweit, so gut. Da syslog.target anscheinend
obsolete ist, habe ich kurzerhand in dem originalen File bacula-fd.service die entsprechenden Abhaengigkeiten geloescht. Neu gestartet, funktioniert. Da aber beim naechsten Update dieses File ueberschrieben wird, wollte ich den "sauberen" Weg gehen.

So wie hier beschrieben ist, kann man einzelne Services anpassen. Dazu habe ich ein File /etc/systemd/system/bacula-fd.service.d/customdependency.conf angelegt mit folgendem Inhalt:
Code:
[Unit]
Requires=
After=
Requires=var-run.mount nss-lookup.target network.target remote-fs.target time-sync.target
After=var-run.mount nss-lookup.target network.target remote-fs.target time-sync.target
Wie man sieht, wird das File beim Neustart des Services auch gefunden, aber die neuen Requires- und After-Direktiven werden ignoriert:
Code:
pit:/etc/systemd/system/bacula-fd.service.d # systemctl status  bacula-fd.service
bacula-fd.service - Bacula File Daemon service
   Loaded: loaded (/lib/systemd/system/bacula-fd.service; enabled)
  Drop-In: /etc/systemd/system/bacula-fd.service.d
           └─customdependency.conf
   Active: failed (Result: exit-code) since Sat 2014-03-29 10:13:48 CET; 29min ago
 Main PID: 8524 (code=exited, status=15)

Mar 29 10:02:58 pit systemd[1]: Unit bacula-fd.service entered failed state.
Mar 29 10:02:58 pit systemd[1]: Starting Bacula File Daemon service...
Mar 29 10:02:58 pit systemd[1]: Started Bacula File Daemon service.
Mar 29 10:13:48 pit systemd[1]: Stopping Bacula File Daemon service...
Mar 29 10:13:48 pit bacula-fd[8524]: Shutting down Bacula service: pit-fd ...
Mar 29 10:13:48 pit systemd[1]: bacula-fd.service: main process exited, code=exited, status=15/n/a
Mar 29 10:13:48 pit systemd[1]: Stopped Bacula File Daemon service.
Mar 29 10:13:48 pit systemd[1]: Unit bacula-fd.service entered failed state.
pit:/etc/systemd/system/bacula-fd.service.d #
Die Fehlermeldung bleibt gleich:-( Wie geht es richtig? Wie kann ich definieren, dass syslog.target keine Voraussetzung fuer den Start von bacula-fd ist?

Gruss Pit.
 

Rain_Maker

Administrator
Teammitglied
Wie Du hier schreibst

http://www.linuxforen.de/forums/showpost.php?p=1813263&postcount=2

hast Du zumindest eine temporäre Lösung gefunden, und sofern das hier

https://wiki.archlinux.org/index.php/Systemd#Writing_custom_.service_files

systemd will parse these *.conf files and apply them on top of the original unit.
bedeutet, daß es zusätzlich "draufgestülpt" wird ("on top of"), wird es auch ohne Verrenkungen damit nicht gehen, da die originale Datei auch noch ausgewertet wird.

Da man aber ein "Requires" mehrfach angeben kann, passt das beschriebene Verhalten genau zu "wird zusätzlich ausgewertet", während eine veränderte Kopie eines Unit-Files in /etc/systemd/system dem "Original" in /usr/lib/systemd/system vorgezogen und das Original ignoriert wird.

Würde man bei solch einem *.conf-File z.B. eine veränderte Direktive für "ExecStart" angeben, dann ist klar, daß damit die "originale" Direktive in /usr/lib/systemd/system/$SERVICE.service ignoriert wird, denn diese Direktive darf man nur einmal angeben.

Ob das nun ein Bug oder ein Feature ist, kann ich nicht beurteilen, auf alle Fälle ist es aber ein Bug im Paket von Bacula, daß es ohne händisches Gefummel nicht startet, weil es einen Service verwenden will, der in der 13.1 nicht mehr per default da ist, also würde ich mich an den Paketersteller wenden bzw. einen Bugreport zu diesem Bacula-Paket eröffnen.

Greetz,

RM
 

pibi

New Member
Salue Rain_Maker

Danke fuer die Antwort. Laut Doku interpretiere ich es zwar so, dass ein "Requires=" (ohne Angabe von Parametern) alle Abhaengigkeiten loescht und nur noch diejenigen aus meinem speziellen Config-File verwendet. Aber evtl. ist die Doku falsch/ungenau, oder es ist tatsaechlich ein Bug.

Sobald ich einen Moment Zeit habe, werde ich es dem Ersteller dieses Pakets rnelden.

Schoenen Sonntag noch und Gruss
Pit.

PS: Die Benutzung Deiner Foren-Software ist sehr "gewoehnungsbeduerftig", um es mal hoeflich auszudruecken :-((
 
Oben