systemd Backup-Service

Hinweis: In dem Thema systemd Backup-Service gibt es 44 Antworten auf 5 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Na ja, das ist alles eigentlich eine Grundeigenschaft aller Linuces.


    Ein Prozess kann in prinzipiell zwei verschiedenen Modi laufen: Interaktiv oder eben nicht interaktiv.


    Reine Serverprogramme laufen immer im nicht-interaktiven Modus.
    Die sollen ja auch im Hintergrund schweigend möglichst schnell und gut ihren Dienst versehen.
    Sie werden einfach gestartet, ohne dass ihnen ein Terminal zugeordnet wird.
    Die können nicht einfach etwas ausgeben.
    Sie schreiben ihre Ausgaben meist in das Systemjournal, oder halt in irgendwelche Dateien, die ihnen per Konfigdatei (oder hardcoded im Binary selbst) zugeordnet werden.


    Interaktive Programme brauchen Tastatur und Bildschirm. Anders macht das ja auch kaum Sinn.
    Werden die gestartet, wird zu allererst einmal ein Terminal gestartet, das seinerseits dann eine Shell oder das jeweilige Programm aufruft.
    Das zugeordnete Terminal verbindet nun die ersten drei Dateidescriptoren (letztlich Integerzahlen von 0 bis zur konfigurierbaren Obergrenze von su -c 'sysctl fs.file-max' ). Dabei ist Nummer 0 das Keyboard, Nummer 1 der Bildschirm und Nummer 2 der Fehlerkanal, der standardmäßig ebenfalls auf den Bildschirm zeigt. Und damit kann das Programm auf dem Bildschirm ausgeben und von der Tastatur lesen. Die Fehler landen ebenfalls -ohne jede Rücksicht auf die möglicherweise gleichzeitig stattfindende "normale" Ausgabe auf dem Bildschirm, was i.d.R. eine völlig chaotische Bildschirmdarstellung zeitigt.


    Shells, wie die bash, können in beiden Modi laufen. Interaktiv sogar als Login-Shell.
    Oder eben, wenn Scripte abgearbeitet werden nicht-interaktive(, oder sogar auch da interaktiv).
    Shells sind nun mal ihrer Natur nach Zwitterwesen.


    Noch etwas anders laufen die Dinge in einer graphischen Konsole.
    Dort wird die erste graphische Konsole distributionsabhängig (und ebenfalls konfigurierbar) meist auf dem Pseudoterminal Nummer 7 gestartet. Es ist somit durch <strg><alt><F7> erreichbar. Dort übernimmt aber der darunterliegende X-Server (oder neuerdings Wayland) alle Input und Outputgeräte. Dazwischengeschaltet kümmert er sich, dass die entsprechenden Fenster die jeweiligen Mausbewegungen und Tastendrücke korrekt erhalten.


    Dein kdialog ist genau zwischen all den herrlichen Kleinigkeiten.
    Ich glaube (bin mir aber nicht sicher), dass sogar kdialog mittlerweile die IPC (InterProcessCommunication) von Linux, also letztlich dbus nutzt.
    Dabei wird das DE angewiesen vom X-Server (oder Wayland) ein neues Fenster zu erzeugen.
    Das geht am Terminal komplett vorbei.
    (Es geht auch komplett am Terminal vorbei, wenn es noch nach der alten Methode direkt mit dem X-Server babbelt)


    Da dein Script solche Ausgaben verwendet, ist es eigentlich kein wirklicher Service, sondern tatsächlich ein interaktives Script.
    Aber egal.


    Das regeln der Reihenfolge in systemd wird damit auch nicht leichter. Das bleibt erst mal undurchsichtig, wie es halt ist.
    Bei systemd liegt das Hauptaugenmerk auf möglichst optimaler Parallelisierung.
    Die Reihenfolge der Abarbeitung aller Scripte wird nicht, wie SysV- Init durch die nummerische Reihenfolge der Scriptnamen ( 10-irgendwas kommt vor 11-irgendwasanderes usw.) geregelt, sondern durch die Definition von sogenannten Targets, worauf sich die Konfiganweisungen BEFORE, AFTER, WANTS und dergleichen beziehen.


    Das kannst du in man systemd.service nachlesen. Die komplette Doku findet sich bei Freedesktop (ganz runterscrollen bis zu Manuals and Documentation for Users and Administrators )

  • systemd-cat wäre eine richtige Variante hinsichtlich Logging, richtig?


    Aus Running Services After the Network is up, Kapitel "Concepts in systemd" hätte ich egtl. herausgelesen, dass After=network.target genau das ist was ich brauche, aber das Netzwerk wird anscheinend deaktiviert bevor das Script ausgeführt wird. Wenn ich das After= in Before= ändere scheint das Verhalten aber exakt dasselbe zu sein.


    Für den Inhalt des Beitrages 115365 haftet ausdrücklich der jeweilige Autor: myscha

  • Man kann auch schlicht logger in Scripten verwenden. (Falls ich das richtig interpretiert habe, und du eine Möglichkeit für das Schreiben in das Systemjounal suchst. systemd-cat is auch OK.
    logger schreibt nur; falls dein Programm auch liest, brauchst du schon systemd-cat.



    In einem Service File werden Abhängigkeiten definiert.
    Die sind beim Shutdown genau umgekehrt.
    Es gibt dafür die schlichte Konfigdirective ExecStop

  • Wie das bei einem Service ist, der WantedBy=multi-user.target ist, habe ich (glaube ich) verstanden. Deinen Beitrag #9 hatte ich aber so gedeutet, dass dies hier nicht der richtige Weg ist, woraus dann die aktuelle Variante entstanden ist.


    Ich habe aber nicht verstanden wie das mit einem Service funktioniert, der beim Herunterfahren ausgeführt wird, sprich dem jetzigen Zustand.

    Für den Inhalt des Beitrages 115466 haftet ausdrücklich der jeweilige Autor: myscha

  • Dank WantedBy=halt.target poweroff.target wird der Service nur beim Herunterfahren ausgeführt. In dem Fall zählt die Reihenfolge beim Starten nicht, oder doch? Und bei ExecStop ist auch nix eingetragen was auf dem Rückweg ausgeführt werden könnte.


    EDIT:

    Meinst du in der Art?

    2 Mal editiert, zuletzt von myscha ()

    Für den Inhalt des Beitrages 115493 haftet ausdrücklich der jeweilige Autor: myscha

  • Die Reihenfolge ist immer gegeben.
    Aber eben halt nicht schlicht offensichtlich. Sie ist implizit vorgegeben.
    Sie spielt immer eine Rolle.


    Und, ja, ich meinte in der Art.
    Das sollte tun.


    Mir ist schon klar, dass das alles nicht so leicht einsehbar ist.
    Aber da musst du einfach selber durch.
    Der Groschen fällt schon bald.


    Dein ExecStart kannst an die Hasen verfüttern.

    true ist übrigens ein echtes Kommando (UND ein internes Shellkommando), du Ressourcenverschwender!

  • Wenn ich ExecStart weglasse oder nur ExecStart= schreibe, lässt sich der Service gar nicht starten.


    Aber auch mit dem ExecStart funktioniert es nicht und wir wären damit dann wieder bei der Version und dem Problem aus dem Eingangspost...

    Für den Inhalt des Beitrages 115512 haftet ausdrücklich der jeweilige Autor: myscha

  • OK. Dann lass es einfach drin.


    Da weiß ich jetzt nicht, was das soll und seit wann das so ist.
    Ich hab das anders in Erinnerung.
    Muß ich erst gucken.
    (irgendwann mal)

  • Es funktioniert ja auch mit ExecStart nicht.


    Ich habe jetzt einen *.desktop-Starter für mein Backup-Skript angelegt der zuerst die Sicherung durchführt und den PC anschließend herunterfährt. Anscheinend ist systemd nicht in der Lage das so zu machen wie ich es gerne hätte... Oder ich bin zu doof...

    Für den Inhalt des Beitrages 115535 haftet ausdrücklich der jeweilige Autor: myscha