Mir sind in einigen Systemd-Dokumentationen und Anleitungen erhebliche Unterschiede in der Vorgehensweise bei der Konfiguration eines oder mehrerer Dienste für die Verwendung desselben Timers aufgefallen.
Soweit ich es zusammentragen konnte (obwohl ich mich irren kann), würde dies beschreiben, was dieGesucht vonUndEinheitParameter in einer Service- und Timer-Datei müssen für einen einzelnen Service bzw. für eine Konfiguration mit mehreren Services unter Verwendung eines einzelnen Timers wie folgt eingestellt werden (hier werden keine tatsächlichen Codebeispiele verwendet, um die Länge des Posts zu verringern):
Timer für einen einzelnen Dienst
My.Service1 'WantedBy' Param: N/A (1)
My.Timer 'Unit' Param: My.Service1 (2)
My.Timer 'WantedBy' Param: MultiUser/Basic.Target (3)
(1)Die Servicedatei benötigt keinen [Install]-Abschnitt mit einem WantedBy-Parameter.
(2)Im Abschnitt [Timer] des Timers sollte der Parameter Unit auf die Servicedatei My.Service1 verweisen.
(3)Die Timerdatei verfügt über einen WantedBy-Parameter, der auf ein spezielles Systemziel verweist, das zum Starten verwendet wird.
Timer für mehrere Dienste
My.Service1 'WantedBy' Param: Timer.Target (1)
My.Service2 'WantedBy' Param: Timer.Target (1)
My.Service3 'WantedBy' Param: Timer.Target (1)
Timer 'Unit' Param: Timer.Target (2)
Timer 'WantedBy' Param: ???
(1)Die Dienste müssen alle über den Parameter WantedBy eine Verbindung zum gleichen definierten Ziel herstellen.
(2)Der Unit-Parameter [Timer] sollte ebenfalls auf das Ziel zeigen.
Ein Beispiel für die letztgenannte Konfiguration finden Sie unterdiese Anleitung. Ich zähle das als Beispiel 1. Ich habe jedoch andere Anleitungsbeispiele gefunden, die davon abweichen (siehe unten).
Beispiel 2UndBeispiel 3sagen wir, es sollte folgendermaßen konfiguriert sein:
My.Service1 WantedBy: Timer.Target
My.Service2 WantedBy: Timer.Target
My.Service3 WantedBy: Timer.Target
Timer 'Unit' Param: My.Service1 (1)
Timer 'WantedBy' Param: MultiUser/Basic.Target
(1) Dies muss ein Versehen in der Dokumentation sein, denn wenn Sie die Einheit nur auf einen Ihrer zahlreichen Dienste zeigen lassen, können die anderen Dienste den Timer nicht verwenden. Möglicherweise lag dies an dem dort verwendeten „siehe oben“-Ansatz, der den Leser auf die Konfiguration des einzelnen Dienstes zurückverwies, ohne tatsächlich (wichtig) zu erwähnen, was geändert werden musste.
Dann mitBeispiel 4seine Konfiguration sieht so aus, als würde sie tatsächlich funktionieren, aber es geht anders an die Verbindung der Dienste mit dem Ziel, indem die Dienstdateien direkt unter dem/etc/systemd/system/Timer.Target.wants/Unterverzeichnis und schließt alle WantedBy-Parameter in den Servicedateien aus. Daher:
My.Service1 'WantedBy' Param: N/A
My.Service2 'WantedBy' Param: N/A
My.Service3 'WantedBy' Param: N/A
Timer 'Unit' Param: Timer.Target
Timer 'WantedBy' Param: MultiUser/Basic.Target
Ein hybrider Ansatz zwischen Beispiel 1 und 4, den ich gesehen habe, besteht darin, die Servicedateien im/etc/systemd/system/Verzeichnis (der Standardspeicherort) und zum Erstellen eines symbolischen Links zu diesen Servicedateien unter dem/etc/systemd/system/Timer.Target.wantsDatei undausschließeneinen WantedBy-Parameter in der Servicedatei (der funktional gleichwertig zu Beispiel 4 ist), während eine andere Konfiguration die Methode des symbolischen Links verwendet, aber zusätzlich den WantedBy-Parameter in die Servicedatei einschließt (was redundant und unnötig erscheint).
Meine Frage wäre jedoch diese für das Beispiel 4 und die hybriden Ansätze: Warum sollte man etwas unter eine*.willVerzeichnis überhaupt notwendig sein, wenn die Deklaration eines WantedBy-Parameters systemd anweisen soll, dies für Sie zu tun (wie in der Erklärung dieses Parameters aufdiese Seite)?
Kann jemand Licht in die Sache bringen, wie man trotz der verwirrenden Vielzahl an Ansätzen am besten mehrere Dienste mit demselben Timer konfiguriert?
Antwort1
Wenn Sie mehrere Dienste mit einem einzigen Timer aktivieren möchten, fügen Sie dazwischen ein Ziel ein:
Die Timer-Einheit, nennen wir sie foo.timer:
[Unit]
Description=My timer that runs saturdays, 9am and triggers foo.target
Wants=foo.target
[Timer]
OnCalendar=Sat 9:00
Unit=foo.target
[Install]
WantedBy=timers.target
Die Zieleinheit, nennen wir sie foo.target:
[Unit]
Description=My target unit, that groups my two services xxx.service and yyy.service
Wants=xxx.service yyy.service
After=xxx.service yyy.service
[Install]
Also=foo.timer
Und dann die beiden Dienste xxx.serviceund yyy.service:
[Unit]
Description=My service XXX
[Service]
ExecStart=/bin/echo I am XXX
[Install]
Also=foo.timer
[Unit]
Description=My service YYY
[Service]
ExecStart=/bin/echo I am YYYY
[Install]
Also=foo.timer
Kopieren Sie diese vier Unit-Dateien ( foo.timer, foo.target, xxx.service, yyy.service) in /etc/systemd/systemd/. Aktivieren und starten Sie dann den Timer durch Ausführen von:
systemctl enable --now foo.timer`
Dadurch wird eine Verbindung foo.timerzu hergestellt timers.target. Dies ist das allgemeine Ziel, das alle verschiedenen auf einem System definierten Timer einbeziehen soll.
systemctl enable foo.targetBeachten Sie, dass Sie übrigens auch und tun könnten systemctl enable zzz.service, da die Also=Zeilen in diesen Einheiten die Aktivierungsanforderungen an weiterleiten foo.timer.
Antwort2
Ein systemd-Timer aktiviert immer eine Einheit.
Wenn Sie zwei Einheiten nach dem gleichen Zeitplan aktivieren möchten, empfehle ich der Übersichtlichkeit halber, zwei Timerdateien zu erstellen, die den gleichen Zeitplan enthalten.
Andernfalls könnten Sie eine „Service Unit“-Datei erstellen, die die beiden gewünschten Dienste startet.
Ich glaube nicht, dass „WantedBy=“ ein besonders nützliches Konzept für Timereinheiten ist.