mögliche Nachteile von systemd Timern

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
piotrusch
Beiträge: 61
Registriert: 08.10.2020 21:12:39

mögliche Nachteile von systemd Timern

Beitrag von piotrusch » 12.02.2021 20:17:49

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

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: mögliche Nachteile von systemd Timern

Beitrag von TRex » 12.02.2021 21:24:26

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?
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

piotrusch
Beiträge: 61
Registriert: 08.10.2020 21:12:39

Re: mögliche Nachteile von systemd Timern

Beitrag von piotrusch » 12.02.2021 22:58:03

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?

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: mögliche Nachteile von systemd Timern

Beitrag von TRex » 12.02.2021 23:21:28

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.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

piotrusch
Beiträge: 61
Registriert: 08.10.2020 21:12:39

Re: mögliche Nachteile von systemd Timern

Beitrag von piotrusch » 13.02.2021 09:22:34

TRex hat geschrieben: ↑ zum Beitrag ↑
12.02.2021 23:21:28
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
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: mögliche Nachteile von systemd Timern

Beitrag von JTH » 13.02.2021 11:48:57

piotrusch hat geschrieben: ↑ zum Beitrag ↑
12.02.2021 20:17:49
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.

piotrusch hat geschrieben: ↑ zum Beitrag ↑
12.02.2021 20:17:49
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.

piotrusch hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 09:22:34
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.

piotrusch hat geschrieben: ↑ zum Beitrag ↑
12.02.2021 22:58:03
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).

piotrusch hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 09:22:34

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.
Manchmal bekannt als Just (another) Terminal Hacker.

piotrusch
Beiträge: 61
Registriert: 08.10.2020 21:12:39

Re: mögliche Nachteile von systemd Timern

Beitrag von piotrusch » 13.02.2021 20:23:36

Danke zunächst mal für deine ausführliche Antwort.
JTH hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 11:48:57
piotrusch hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 09:22:34
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?
JTH hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 11:48:57
piotrusch hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 09:22:34

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.
JTH hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 11:48:57
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
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: mögliche Nachteile von systemd Timern

Beitrag von JTH » 16.02.2021 11:15:21

piotrusch hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 20:23:36
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.

piotrusch hat geschrieben: ↑ zum Beitrag ↑
13.02.2021 20:23:36
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.
Manchmal bekannt als Just (another) Terminal Hacker.

Antworten