this post was submitted on 07 Jun 2025
5 points (100.0% liked)

Linux

605 readers
1 users here now

Linux Begeisterte können sich hier austauschen!

Bitte die Feddit.ORG Instanz-Regeln beachten!

founded 1 year ago
MODERATORS
 

Oder, wie kann man das konfigurieren dass sie sich nicht überlappen, bzw. das Programm das sie ausführen. Und am liebsten so dass der zuletzt gestartete nachgeholt wird sobald möglich.

Ich weiss dass ich sowas auch im Skript codieren kann, aber ich dachte mir 💡sollte systemd hier nicht glänzen?

Meine Suchmaschinenbändigungskünste funktionieren grad nicht so gut.

Danke im voraus.


Zur Zeit habe ich das allersimpelste was es gibt:

[Unit]
Description=irgendwas

[Service]
ExecStart=/usr/bin/irgendwas

Normalerweise wird dieser Service über einen Timer gestartet, wird manchmal aber auch bei Dateiänderungen getriggert. Bzw. Das Skript. Das ist eben die Frage, was ist da besser: Das Skript direkt triggern und eine Lock-Funktion einbauen, oder kann man da auf systemd vertrauen?

you are viewing a single comment's thread
view the rest of the comments
[–] A_norny_mousse@feddit.org 2 points 1 month ago (1 children)

Danke für die Gedanken bzw. Bestätigung dass mein gefühltes Wissen korrekt ist.

Ja, ich glaube oneshot und die unterschiedlichen Types muss ich mir genauer anschauen.

[–] elvith@feddit.org 2 points 1 month ago* (last edited 1 month ago)

Oneshot bedeutet, dass der Prozess nicht dauerhaft aktiv ist.

Beispielsweise hatte ich das autoupdate eines Docker Stacks so realisiert:

Der Stack hatte eine docker-compose mit den Definitionen für Network, Container, Volumes,… zusätzlich gab es diverse Konfig, die in unterordner waren und eben über die genannten Volumes in die jeweiligen Container gemountet wurden. Die ganze Config, docker-compose,… lag in einem git-repo von mir.

Dazu gab es eine systemd Unit, die als Start command ein docker compose up -d und als Stop command ein docker compose down hatte.

Für das Auto-Update hab ich ne zweite Unit angelegt:

  • Typ=oneshot, damit es eben ein Script ist, was nach dem beenden nicht sofort neu gestartet wird
  • conflicts= die oben genannte Unit des stacks. Damit wird bei Start dieser Unit automatisch ein stop auf den Stack gemacht
  • execstart= ein shellscript mit git pull und docker compose pull
  • danach dann wieder die Unit des stacks gestartet - ich weiß nicht mehr, ob ich das über ExecStartPost gemacht hab, oder ob es dafür einen eigenen Verweis auf andere Units gab…

Und dann einen Timer, der regelmäßig den oneshot Dienst getriggert hat - IIRC nächtlich um 2 Uhr