shutdown und reboot signal/sigterm lesen/unterscheiden

L I V E Stammtisch ab 20:30 Uhr im Chat
  • 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 und reboot signal/sigterm lesen/unterscheiden? Schau mal ob du hier fündig wirst!

  • ..., Shutdown ist eine Datei in /sbin/. Kann man öffnen und lesen.

    BTW: Der TE hat stretch:

    Code
    :~ $ file /sbin/shutdown
    /sbin/shutdown: symbolic link to /bin/systemctl
    Code
    :~ $ ls -la /sbin/shutdown
    lrwxrwxrwx 1 root root 14 May  7  2017 /sbin/shutdown -> /bin/systemctl

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

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

    Evtl. kannst Du das mit der service unit (systemd-reboot.service, systemd-poweroff.service, systemd-halt.service) machen (z. B. in der [Service]-Section).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • ... zwischen Reboot und Halt einen Unterschied gibt.

    Zu welchem Zeitpunkt willst Du feststellen, ob es ein Reboot oder ein Halt ist? Auf welche Art und Weise verwertest Du danach diese Information (... d. h. die Unterscheidung zwischen Reboot und Halt)?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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.

    • Offizieller Beitrag

    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.

  • ... 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:

    Spoiler anzeigen

    SIGRTMIN+3

    Halts the machine, starts the halt.target unit. This is mostly

    equivalent to systemctl start halt.target.

    SIGRTMIN+4

    Powers off the machine, starts the poweroff.target unit. This is

    mostly equivalent to systemctl start poweroff.target.

    SIGRTMIN+5

    Reboots the machine, starts the reboot.target unit. This is

    mostly equivalent to systemctl start reboot.target.

    SIGRTMIN+6

    Reboots the machine via kexec, starts the kexec.target unit. This

    is mostly equivalent to systemctl start kexec.target.

    SIGRTMIN+13

    Immediately halts the machine.

    SIGRTMIN+14

    Immediately powers off the machine.

    SIGRTMIN+15

    Immediately reboots the machine.

    SIGRTMIN+16

    Immediately reboots the machine with kexec.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • ... sieh Dir mal die Signale an, die der TE abgefangen hat: 1, 15, 18.

    Ja, ...

    Code
    :~$ kill -l 1 15 18
    HUP
    TERM
    CONT

    ... da muss der TE noch etwas üben. ;)

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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:

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

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

    Code
    # journalctl -b -1 | egrep "start-before-shutdown|create-journal"
    Nov 08 17:01:32 thomaspc systemd[1]: Starting thlu:start-before-shutdown.service: Start at shutdown, reboot, halt...
    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=
    Nov 08 17:01:32 thomaspc systemd[1]: Started thlu:start-before-shutdown.service: Start at shutdown, reboot, halt.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!