eigener Service wird unter Leap 42.2 mehrfach ausgeführt

Hinweis: In dem Thema eigener Service wird unter Leap 42.2 mehrfach ausgeführt gibt es 7 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Hallo,


    ich bin eben dabei, mein System von openSUSE 13.2 auf Leap 42.2 umzustellen.


    Dabei habe ich ein Problem mit einem eigenen Service, den ich für Zwecke der Datensicherung geschrieben habe.
    Die Idee ist, den Service bei Systemstart zu starten. Der Service tut erstmals nichts. Erst wenn das System runtergefahren wird, soll ein Skript über alle (für mich) wichtigen Ordner gehen und auf separaten Disks Datensicherungsfiles erstellen, wenn sich gegenüber der letzten Sicherung etwas geändert hat.


    Unter 13.2 läuft dieses Konzept einwandfrei. Unter 42.2 beobachte ich nun, daß mein Sicherungsskript auch bei Systemstart ausgeführt wird. Das ist zwar kein Beinbruch, weil bei Systemstop evt. vorhandene Sicherungsdateien des gleichen Tags überschrieben werden. Der Systemstart verzögert sich aber dadurch, d.h. der Start von 42.2 dauert erheblich länger als der Start von 13.2 und daran beteiligt ist mein Skript.


    Ich weiß, daß das Skript ausgeführt wird, weil ich an dessen Ende auf dem Systemlautsprecher eine Tonleiter ausgebe und diese kommt eben unter 42.2 einige Zeit nach dem Start und dann nochmals kurz vor dem Ende, während es bei 13.2 nur kurz vor dem Ende kommt. Der Tonleiter vorausgehend ist lt. Disk-Acivity-LED ziemliche Last auf den Platten (auch typisch für mein Skript).


    Kann mir jemand einen Tip geben? was hat sich an Systemd geändert von 13.2 nach 42.2? Im Anhang die frageliche Service-Datei.

  • Bitte Dateien nur anhängen, wenn sie für das Posten zu groß sind.
    Solche Sachen bitte in Code-Tags direkt reinschreiben.


    Wo ist das Servicefile für diesen Job?
    Das halt-local ist erst mal nicht relevant.
    Zeigt aber schon in die richtige Richtung.
    Das wird dein BEFORE Statement im Servicefile

  • Sorry, ok mache ich künftig so (mit den angehängten Dateien).


    Das Service File steht unter /usr/lib/systemd/system/
    und ein Link darauf unter: /usr/lib/systemd/system/multi-user.target.wants


    Dieses Link wird erstellt, wenn ich das Kommando eingebe


    Code
    systemctl enable halt-local.service

    schließlich habe ich noch eingegeben:


    Code
    systemctl start halt-local.service

    Dies um den Service einmalig zu starten. Beim letzten Kommando wird im übrigen kein Sicherungslauf angestossen.(wie ich es auch beabsichtigt habe)..
    Da ich auch mit dem Kommando mysqldump noch Daten aus einer Mysql-Datenbank exportieren will, muß mysql zum Zeitpunkt des Skripts laufen.


    Wie gesagt: unter 13.2 läuft das ganze exakt so, wie es beabsichtigt ist.

    Für den Inhalt des Beitrages 111738 haftet ausdrücklich der jeweilige Autor: Suelkun

  • Ich wollte das Servicefile von DEINEM Service lesen.
    Nicht den Defaultkäse.



    Ich schließe daraus, dass dir da ein wesentlicher Punkt, wie systemd arbeitet, entgangen ist.
    Du brauchst für dein Script ein eigenes Servicefile, und das hat als Target den Systemshutdown und die Bedingung BEFORE mysql Shutdown.


    Wenn du das nicht hast, wird es über den Kompatiblitätsmodus gestartet.
    Das meint, du hast ein altes SysV - Initscript irgendwo rumliegen.
    (Oder keines davon, was auch geht, aber noch schlimmer ist.)


    man systemd.service gibt erste Hinweise.
    Und hier hab ich mal ein Minitutorial eingestellt, das mit Systemd Timers rummacht. Suche es und nimm das als Einstiegshilfe.

  • ok, ein Mißverständnis, hier ist mein Service-File::


    Nachdem mysql.service von network.target abhängt, reicht es unter 13.2 auch, wenn in der Unit-Section die Abhängigkeit nur von mysql.service reinschreibe. Es läuft auch dann unter 13.2 wie beabsichtigt.


    Unter 42.2 hingegen wird der Service auch dann mehrfach ausgeführt (also bei Systemstart und Systemstop), wenn ich die Abhängigkeit von mysql.service ganz rausnehme, d.h. wenn meine Zeile After=... dann lautet:

    Code
    After=network.target

    einziger Nachteil dabei: Dann funktioniert der DB-Export nicht mehr.
    Das aufgeführte Service file ist in den Pfaden abgelegt, die ich in meinem letzten Posting genannt habe.


    Aber Du hast recht, ich schaue mir das Tutorial an. Wenn es Möglichkeiten gibt, auf das Shutdown eines Prozesses zu warten und dann etwas auszuführen, das wäre für mich viel einfacher.

    Für den Inhalt des Beitrages 111774 haftet ausdrücklich der jeweilige Autor: Suelkun

  • Problem ist gelöst.


    Es gibt auch ein Service-File halt.local.service, welches prinzipiell mit der Distribution kommt. Ich weiß zwar momentan nicht, wo dieses Service-File steht, aber der Dienst war da und er war aktiv.


    Ich habe Leap42.2 installiert durch upgrade meines 13.2, d.h. der Dienst halt.local.service ist von 13.2 beim upgrade übernommen worden. Jedenfalls führte dieser Dienst auch mein Script aus, ein Relikt von früheren Basteleien.
    Ich mußte bisher bei jedem upgrade den "orginal"-Dienst deaktivieren und unter leap 42.2 habe ich das vergessen, sorry.


    Dazu hin habe ich "meinen" Dienst auch noch ziemlich gleich benannt (halt-local.service), was vielleicht auch noch fehlerträchtig ist und gar nicht notwendig.


    Jedenfalls kommt leap42.2 jetzt hoch, ohne sich gleich auf die Datensicherung zu stürzen. Deaktivieren und stoppen des Dienstes halt.local.service (via Yast) hat ausgereicht.

    Für den Inhalt des Beitrages 111779 haftet ausdrücklich der jeweilige Autor: Suelkun

  • ... noch ein kleiner Nachtrag.


    Das Service file zum Dienst halt.local.service liegt im Ordner /var/run/systemd/genarator.late.


    Dieser Dienst führt dann bei Start und Ende des Mehrbenutzerbetriebs auch noch das Script /etc/init.d/halt.local.sh aus und das ist genau mein Datensicherungsscript!

    Für den Inhalt des Beitrages 111780 haftet ausdrücklich der jeweilige Autor: Suelkun

  • Es ist keine gute Idee, das Target auf Networkshutdown zu legen.
    Denn damit kann es dann passieren, dass mysql zeitgleich mit deinem Script beendet wird.
    Die Statements BEFORE und AFTER dienen genau dazu.


    Du führst tatsächlich via Kompatibilitätslayer ein altes SystemV Initd - Script aus.
    Das ist nicht, was du willst.
    (Auch wenn es funktioniert, aber mit gewissen Schmerzen)


    Es ist sehr viel einfacher den Job über ein eigenes Servicefile, das du selbst zu deinem Shellscript erst erstellen musst, aufzurufen.


    Da systemd mit an Sicherheit grenzender Wahrscheinlichkeit die nächsten Jahre am Start bleiben wird,
    sollte man es richtig lernen.