shutdown und reboot signal/sigterm lesen/unterscheiden

  • Hallo


    ich suche eine Möglichkeit, reboot und shutdown Befehle in einem Phyton Script zu lesen und zu unterscheiden.

    Zielsystem ist ein Raspberry Pi 2 Model B Rev 1.1, mit Raspbian GNU/Linux 9 (stretch) und Python2.


    Ich habe einen Weg gefunden an die sigterm's zu kommen. (https://www.raspberrypi.org/forums/viewtopic.php?t=149939)

    Das ergibt dann folgende Ausgabe, egal ob ich Shutdown/Halt oder Reboot benutze.

    (Datei: 2.log)

    Ich hatte gehofft das sich zwischen Reboot und Halt einen Unterschied gibt.

    Gibt es noch weiter Möglichkeiten zwischen Neustart und Halt zu unterscheiden?:?:


    MfG

    Magier

  • Shutdown Befehle lesen? Ok, wozu auch immer, Shutdown ist eine Datei in /sbin/. Kann man öffnen und lesen.


    Möchtest Du den Shutdown aus Python nun auslösen oder abfangen?

  • Servus magier ,

    da sehe ich nur eine Möglichkeit: das Signal mit -> sigaction <- abfangen und dann die siginfo_t Struktur auswerten ... da steht die ID des sendenen Prozesses drin. Aus dessen Kontext könnte das hervorgehen ...

    Aber wie man das jetzt in Python umsetzt - da müssen andere her, das ist nicht meine Welt ;)


    cu,

    -ds-

  • da sehe ich nur eine Möglichkeit: das Signal mit -> sigaction <- abfangen und dann die siginfo_t Struktur auswerten ... da steht die ID des sendenen Prozesses drin. Aus dessen Kontext könnte das hervorgehen ...

    nee, tut's nicht...ist immer sigterm.... und der Sender ist immer systemctl. Ich verstehe sowieso nicht, warum das so kompliziert gelöst werden soll... das ist doch Basis-Funktionalität von systemd. Man braucht doch bloss eine Wrapper-Unit für das entsprechende systemd-Target, der Rest ist doch dann einfach. Man muss sich halt mit systemd auseinandersetzen, was ich aber für den besseren Weg halte, als irgendwelchen wackeligen Basteleien.


    Jm2c

  • Also hab ich das jetzt richtig verstanden: Du wollst das herausfinden in der kurzen Zeit, wo der Prozess ein SIGTERM bekommen hat (was man abfangen kann), aber noch nicht aus dem Speicher rausgeräumt worden ist (SIGKILL kann man nicht abfabgen)?

  • (SIGKILL kann man nicht abfabgen)?

    Wie soll das gehen...?... der Prozess kriegt den sigkill doch gar nicht mit.... und sigkill ist auch gar kein Signal für den Prozess. sigkill veranlasst lediglich, dass der Prozess getötet wird. "wird" bedeutet, das ist nicht die Aufforderung an den Prozess, sich selber zu töten.... dafür ist sigterm gedacht.

  • Ich verstehe nicht was Signale mit shutdown oder reboot zu tun haben sollten, bzw. warum man aus den Signalen Rückschlüsse auf ein Herunterfahren ziehen können sollte. :conf:

    Imho wird das System keinen Unterschied zwischen poweroff oder reboot bei den Signalen machen um Prozesse zu beenden. Der Sinn des ganzen erschließt sich mir auch nicht wirklich.

    "Alles, was wir sind, ist Sand im Wind, Hoschi."

  • ... wird das System keinen Unterschied zwischen poweroff oder reboot bei den Signalen machen um Prozesse zu beenden.

    Lt. manpage von systemd gibt es da schon verschiedene Signale für poweroff und reboot:


  • Richtig, aber sieh Dir mal die Signale an, die der TE abgefangen hat: 1, 15, 18. Außerdem wenn, dann wäre vermutlich das Modul sys die sinnvollere Wahl.

    "Alles, was wir sind, ist Sand im Wind, Hoschi."

  • Lt. manpage von systemd gibt es da schon verschiedene Signale für poweroff und reboot:

    Meiner Meinung nach gibt es die 'außerhalb' von systemd nicht. Hast Du noch den Link, dass man mal den Kontext nachlesen kann. So sagen diese isoliert dargestellten Werte ja eigentlich gar nix aus. Nach meiner Kenntnis fordert systemd bei Poweroff und Reboot einen Prozess zuerst mit "sigterm" auf sich zu beenden. Reagiert der Prozess darauf nicht, wird er nach dem Timeout via "sigkill"-Signal getötet. Vom letzteren kriegt der Prozess m.E. nix mit bzw. er bekommt keine vorherige weitere Info... denn den sigterm hat er ja bekommen. Die Unterschiede der systemd-internen Signalbehandlung sind meiner Meinung nur für die entsprechenden Targets relevant.... also systemd-internes Geschäft.Die eigentlichen Prozesse können sich die Targets und entsprechende Statement After und Before zunutze machen und sind damit zuverlässig informiert bzw. tangiert.

  • Wenn ich den Link aus #7 richtig verstanden habe, ist der Unterschied, daß jeweils ein unterschiedliches Target (reboot.target bzw. shutdown.target oder halt.target) gestartet wird. Das müsste sich doch auch irgendwie abfragen lassen. ThomasL : Weisst Du aus dem Stand wie?

  • Weisst Du aus dem Stand wie?

    Ja, sicher... das hatte ich schon vor Jahren mal aus Neugier beim Einarbeiten in systemd gelöst. Wie gesagt... ne einfache Unit regelt das für 3 Situationen... oder 3 separate Units, wenn man differenzieren will. Und ja, es lohnt sich, sich in systemd einzuarbeiten... das ist ein geniales Teil.



    Das aufgerufene Mini-Script:

    Shell-Script
    1. #!/bin/bash
    2. echo "User=$USER, Parm1=$1 Parm2=$2 Parm3=$3" | systemd-cat -t "thlu:$(basename $0)" -p info
    3. exit 0


    Führt zu folgenden Eintrag im Journal "boot -1":

    Code
    1. # journalctl -b -1 | egrep "start-before-shutdown|create-journal"
    2. Nov 08 17:01:32 thomaspc systemd[1]: Starting thlu:start-before-shutdown.service: Start at shutdown, reboot, halt...
    3. Nov 08 17:01:32 thomaspc thlu:create-journal-entry[3140]: User=, Parm1=started from before-shutdown.service (shutdown/reboot/halt Parm2=active/running Parm3=
    4. Nov 08 17:01:32 thomaspc systemd[1]: Started thlu:start-before-shutdown.service: Start at shutdown, reboot, halt.