mögliche Nachteile von systemd Timern

[piotrusch]

Hallo zusammen,

bei mir läuft eine kleine Media-box, die sowohl Deskop (Kodi am TV) als auch Server (smb, nfs, usw.) ist. Seit Kurzem läuft auch Docker darauf mit einer Nginx- und einer Nextcloud-Instanz. Seither braucht GDM ewig um zu starten.

Die Suche "systemd start service with delay" brachte mich schnell zur Timer-Funktionalität:

/etc/systemd/system/docker.timer

Code: Alles auswählen

[Unit]
Description=Starte docker mit Verzug, um GDM schneller starten zu lassen

[Timer]
OnBootSec=2min

[Install]
WantedBy=timers.target

Der Start geht jetzt wieder so schnell wie früher und Docker kommt mit etwas Verzögerung auch hoch.

Jetzt meine Frage dazu: handle ich mir damit Nachteile ein? Ich musste logischerweise den docker.service deaktivieren. Das bedeutet dann doch, dass Docker nicht mehr automatisch neu startet, wenn der Service krepiert?

Gruß, piotrusch

[TRex]

Der Titel ist n bisschen vermurkst, ich dachte, du willst ne Grundsatzdiskussion zu systemd-Timern starten...

Zum Thema: Wie wärs alternativ mit ner Abhängigkeit zu gdm?

[piotrusch]

Zum Thema: Wie wärs alternativ mit ner Abhängigkeit zu gdm?

Gerade probiert. Leider startet der Rechner damit wieder deutlich langsamer. Im Netz findet man dafür auch eine einfache Erklärung: Docker startet damit lediglich nachdem GDM gestartet ist, nicht aber nachdem GDM wirklich läuft. So kommen sich die beiden in die Quere und es dauert.
Im Netz gab es Hinweise, das mit "type=oneshot" lösen zu können, aber da weiß ich nicht, was das für Nebeneffekte hat.

Weißt du, was mit dem Docker-Service passiert, wenn ich ihn über den Timer starte? Geht damit die Neustart-Funktionalität verloren?

[TRex]

Nein, aber du könntest ja den Dienst einfach mal per kill lynchen und sehen, was passiert. Nimm nen eigenen oder nen unwichtigen, wenn du glaubst, dass docker damit ein Problem hat.

[piotrusch]

Nein, aber du könntest ja den Dienst einfach mal per kill lynchen und sehen, was passiert. Nimm nen eigenen oder nen unwichtigen, wenn du glaubst, dass docker damit ein Problem hat.

Habe es direkt mit Docker probiert und er startet wie erwartet NICHT neu. Das ist demnach doch keine Option.

Ich habe jetzt für docker.service folgende Option ergänzt:

Code: Alles auswählen

[Unit]
After=network-online.target docker.socket firewalld.service gdm3.service

[Service]
ExecStartPre=/bin/sleep 15

Damit klappt es auch. Einziger Nachteil: bei jedem manuellen Neustart von Docker muss ich 15s warten.

[JTH]

Jetzt meine Frage dazu: handle ich mir damit Nachteile ein?

Nein, tust du nicht. Solange du keine anderen Abhängigkeiten auf den Docker-Daemon hast.

Ich musste logischerweise den docker.service deaktivieren. Das bedeutet dann doch, dass Docker nicht mehr automatisch neu startet, wenn der Service krepiert?

Nein, tut es nicht. Deaktivieren hat nur zur Folge, dass der Dienst nicht durch Abhängigkeiten (beim Boot) gestartet wird. Das Deaktivieren ändert nix am Verhalten des Dienstes, wenn er erstmal läuft – wie auch immer er gestartet wurde.

Habe es direkt mit Docker probiert und er startet wie erwartet NICHT neu. Das ist demnach doch keine Option.

Das hat nichts mit dem Timer zu tun, der ändert nichts am Verhalten des Dienstes selbst. Der Docker-Daemon (und quasi alle systemd-Dienste) wird generell (die Möglichkeit gibt es aber) nicht neugestartet, wenn er sich beendet. Außer er crasht oder wird wirklich gelyncht, z.B. durch ein kill -9. Ein kill ohne Argument sendet ein SIGTERM, damit beendet sich docker aber noch sauber und wird nicht neugestartet.

Im Netz gab es Hinweise, das mit "type=oneshot" lösen zu können, aber da weiß ich nicht, was das für Nebeneffekte hat.

Das könnte lustige Effekte haben, noch längere Wartezeiten verursachen oder den Boot sogar komplett kaputt machen. Ein Dienst mit Type=oneshot muss sich beendet haben, bevor die weiteren Sachen ausgeführt werden. Gdm, Docker etc. beenden sich aber nicht, sondern laufen durchgehend im Hintergrund. Die Option könnte also einen endlosen Hänger verursachen (bevor irgendwelche Timeouts greifen).

Code: Alles auswählen

[Unit]
After=network-online.target docker.socket firewalld.service gdm3.service

[Service]
ExecStartPre=/bin/sleep 15

Damit klappt es auch. Einziger Nachteil: bei jedem manuellen Neustart von Docker muss ich 15s warten.

Wenn dich die 15s stören, verändert der von dir erst probierte Timer wie geschrieben am Service selbst auch nix.

Das ergänzte gdm3.service in der After=-Zeile alleine ist keine Abhilfe? Das Ganze wird, wie TRex schreibt, vermutlich an irgendwelchen Abhängigkeiten liegen.

[piotrusch]

Danke zunächst mal für deine ausführliche Antwort.

Habe es direkt mit Docker probiert und er startet wie erwartet NICHT neu. Das ist demnach doch keine Option.

Das hat nichts mit dem Timer zu tun, der ändert nichts am Verhalten des Dienstes selbst. Der Docker-Daemon (und quasi alle systemd-Dienste) wird generell (die Möglichkeit gibt es aber) nicht neugestartet, wenn er sich beendet. Außer er crasht oder wird wirklich gelyncht, z.B. durch ein kill -9. Ein kill ohne Argument sendet ein SIGTERM, damit beendet sich docker aber noch sauber und wird nicht neugestartet.

Einen möglichen Crash hatte ich bei meiner Frage schon im Hintergrund. Mit aktivierter Service-Unit würde er dann wenigstens versuchen neu zu starten und beim Timer nicht, richtig? Wenn er einmal crasht, dann vermutlich auch danach weiter, aber es scheint mir etwas sicherer, wenn er wenigstens versucht neuzustarten. Oder irre ich mich da?

Code: Alles auswählen

[Unit]
After=network-online.target docker.socket firewalld.service gdm3.service

[Service]
ExecStartPre=/bin/sleep 15

Damit klappt es auch. Einziger Nachteil: bei jedem manuellen Neustart von Docker muss ich 15s warten.

Wenn dich die 15s stören, verändert der von dir erst probierte Timer wie geschrieben am Service selbst auch nix.

Wenn ich den Timer verwenden würde, dann hätte das den Vorteil, dass ich beim manuellen Neustart von Docker (beim Basteln z.B.) die 15s nicht warten muss, weil ich sie aus der service-Konfiguration rausnehmen kann. Aber die 15s sind nicht dramatisch.

Das ergänzte gdm3.service in der After=-Zeile alleine ist keine Abhilfe? Das Ganze wird, wie TRex schreibt, vermutlich an irgendwelchen Abhängigkeiten liegen.

Nein, das hat genau so lange gedauert wie vorher, weil der docker.service quasi direkt startet, nachdem gdm3.service begonnen (!) hat zu starten. Es sei an dieser Stelle erwähnt, dass das System ein i3 mit einer HDD ist. Beides parallel zu starten, scheint es zu überfordern.

[JTH]

Mit aktivierter Service-Unit würde er dann wenigstens versuchen neu zu starten und beim Timer nicht, richtig?

Nein, das ist falsch. Wenn ein Service so konfiguriert ist, bei einem Crash neugestartet zu werden, wird er neugestartet – egal ob er durch einen Timer gestartet wurde oder enabled ist.

Für deine Situation: Der Timer ist okay, der Docker-Daemon wird bei einem Crash trotzdem neugestartet.

Es sei an dieser Stelle erwähnt, dass das System ein i3 mit einer HDD ist. Beides parallel zu starten, scheint es zu überfordern.

Joa, das könnte wohl der Grund sein.