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?

  • Elvith Ma'for@feddit.org
    4·
    28 days ago

    Ich hab’s bislang nicht geschafft, ein Programm/Script/… Über systemd doppelt auszuführen. Je nach Tool solltest du auch noch den Command für den Shutdown eintragen

    Was systemd nicht verhindert ist, wenn du das Tool unabhängig manuell aufrufst. Dann kann es doppelt laufen (wenn das Tool das zulässt).

    Also

    ~$ systemctl start irgendwas
~$ systemctl start irgendwas

    Sollte zu nur einem Aufruf führen (sofern der Service nicht ein oneshot-service ist und sich schon beendet hat, bevor du den zweiten Befehl tippst).

    ~$ systemctl start irgendwas
~$ /ist/bin/irgendwas &

    Würde ggf doppelt starten

    • A_norny_mousse@feddit.orgOP
      2·
      27 days ago

      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 Ma'for@feddit.org
        2·
        27 days 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

  • Tealk@rollenspiel.forum
    3·
    28 days ago

    Also wenn du schon einen systemd service erstellst, wrüde ich das immer darüber laufen lassen, weil:

    • Keine mehrfache Ausführung
    • Logging inbegriffen
    • Status leicht einsehbar

    Zum mehrfach starten: Systemd unterstützt sogenannte “templated services”. Dabei wird eine Dienstdatei mit einem Platzhalter (z. B. @) erstellt, z. B. [email protected]. Beim Starten des Dienstes kann dann eine Instanz angegeben werden, z. B. systemctl start myservice@instance1 und systemctl start myservice@instance2. Jede Instanz läuft dann unabhängig voneinander.

  • captain_unicode@feddit.org
    2·
    28 days ago

    Das sollte bei einem Standard-Daemon nicht gehen. Kann sein, dass systemd noch einen unit-Typ hat, bei dem mehrere Instanzen laufen können. Die offizielle Dokumentation war vor ein paar Jahren bei freedesktop.org, also… RTM?