shutdown und reboot signal/sigterm lesen/unterscheiden

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Puhhh und LOL :conf: ....interessante Diskussion. Muss zugeben ich bin etwas verwirrt. Was Units sind und was sie genau machen, muss ich mir erst anlesen. Aus dem Script ein Daemon machen, müsste ich auch nachsehen, wäre wohl aber auch kein Problem.

    Sinn und Zweck der RS232 Verbindung ist es das der Pi, mitbekommt wenn der Netzstrom weg ist. Daher muss sie halt offen sein...

    Was ist den nun ein praktikabler Weg?

  • shutdown und reboot signal/sigterm lesen/unterscheiden? Schau mal ob du hier fündig wirst!

  • Dann hast Du nicht aufmerksam gelesen, was ich in #20 geschrieben habe.

    Diese Unterstellung kann ich so nicht akzeptieren. Möglicherweise habe ich mich aber nicht klar genug ausgedrückt: Meine Frage ist, ob es ohne eine weitere unit zu erstellen möglich ist, zu unterscheiden, ob systemd gerade einen shutdown oder einen reboot ausführt.

  • Also ich muss sagen ich verstehe den ganzen Zweck immer noch nicht.

    #1 gibt überhaupt keine Infos her.

    Habe mich wohl etwas unklar ausgedrückt. Sorry. Will den Befehl/Signal nicht lesen (Datei öffnen -> rein schauen) sondern ich will in Python wissen ob ein Shutdown oder Reboot Befehl abgesetzt worden ist.


    Ich verwende das in einem Projekt in dem ich meinen Pi, bei Stromausfall, sicher herunter fahren kann

    Hier fehlt eindeutig die Erläuterung, wer analysiert ob der Netzstrom weg ist? Wie wird diese Information weitergegeben? Von wem kommt die Information?

    Warum willst du Unterscheiden zwischen einem Reboot und einem Halt (oder Shutdown)?

    In all den Fällen musst du doch dein Skript ordentlich beenden lassen?

    EDIT:
    Einfach mal bitte das Gesamtziel beschreiben ohne zusehr ins Detail der Umsetzung zu gehen.

  • Meine Frage ist, ob es ohne eine weitere unit zu erstellen möglich ist, zu unterscheiden, ob systemd gerade einen shutdown oder einen reboot ausführt.

    Ja, das sollte mit einem Script (oder gleichwertig) im Verzeichnis "/lib/systemd/system-shutdown/", auch _ohne_ eine service unit möglich sein.

    Denn so kann mit dem an das Script übergebene argument unterschieden werden, ob es ein reboot oder ein poweroff/halt ist. Z. B. aus der manpage von systemd-shutdown:

    Zitat

    Immediately before executing the actual system halt/poweroff/reboot/kexec systemd-shutdown will run all

    executables in /lib/systemd/system-shutdown/ and pass one arguments to them: either "halt", "poweroff",

    "reboot" or "kexec", depending on the chosen action. All executables in this directory are executed in

    parallel, and execution of the action is not continued before all executables finished.

    Es ist nur etwas aufwendig, denn der Datenträger ist zu diesem Zeitpunkt schon ausgehängt (ro), aber man kann diesen mit dem Script ja mounten (rw) und danach wieder aushängen(ro). Das ist aber auch nur dann erforderlich, wenn man auf den Datenträger schreiben will.

    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

    Einmal editiert, zuletzt von rpi444 (9. November 2018 um 07:51)

  • Sinn und Zweck der RS232 Verbindung ist es das der Pi, mitbekommt wenn der Netzstrom weg ist. ...

    Was ist den nun ein praktikabler Weg?

    Ein praktikabler Weg wäre m. E. ein _manuell_ ausführbares Script, zum "Informieren" des PI, dass in kürze der Netzstrom weg ist und zum anschließenden reboot oder poweroff/halt, in Abhängigkeit vom an das Script übergebene argument.

    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

  • Habe mich wohl etwas unklar ausgedrückt. Sorry. Will den Befehl/Signal nicht lesen (Datei öffnen -> rein schauen) sondern ich will in Python wissen ob ein Shutdown oder Reboot Befehl abgesetzt worden ist.

    oh ja, ich hatte nicht mal verstanden was das Ziel war.

    Nun langsam dämmerts.

    Ich hatte so ein ähnliches Problem mit der Fernbedienung meiner mediaPIs

    Manchmal verklickte ich mich und wählte shutdown statt reboot.

    Das ist fatal wenn man nicht daheim ist und den Pi wieder wecken kann.

    Deswegen konnte ich unter wheezy ein bash machen welches ich shutdown nannte, das orignial shutdown umbenannte

    Mein shutdown.sh machte dann reboot und ein shutdown trat so niemals auf.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Was ist den nun ein praktikabler Weg?

    Ein praktikabler Weg ist meiner Meinung nach (und das imho alternativlos) ein "sauberes" Programm-Design. Und das bedeutet primär, das man nicht an dem Systemmanager dran vorbeifummelt oder den außer Acht lässt... denn der Systemmanager ist primär für die Integrität eines laufenden Betriebssystems verantwortlich und infolgedessen für einen kontrollierten Start sowie für das geordnete/kontrollierte Runterfahren des Systems verantwortlich.... eben genau aus dem Grund, dass keine Daten verloren gehen, nur weil Laufwerke oder das Netzwerk beendet wurden, obwohl sie vielleicht noch gebraucht werden. Ein Remount eines bereits geschlossenen Filesystems in der Runterfahr-Phase ist nix anderes als ein ziemlicher Dirty-Hack.

    Ein imho sauberer Weg ist es, die Schnittstellen-Überwachung ohne Ausgaben (dafür Journaleinträge) als Daemon von systemd während des Boots starten zu lassen und Visualisierung (sofern die notwendig ist) mit einem eigenen Prozess im User-Space vorzunehmen, wenn X verfügbar ist. Und selbstverständlich reagiert der Daemon auf sigterm und beendet sich ordentlich, wenn ihn der systemmanager (beim reboot/shutdown) dazu auffordert. Damit gibt es dann überhaupt keine systemischen Interessenkonflikte mehr oder gar verlorengegangene Daten.

    Wenn die Frage nach der Unterscheidung Reboot oder Poweroff nicht nur rein akademischer Natur ist ( was sie imho aber in diesem Fall ist, denn am Ende resultiert aus dem Reboot auch ein Shutdown, insofern kanns dem Job egal sein und es hat auch auf das notwendig zu tuende keinen Einfluss), dann ließe sich das gemäß rpi444's Man-Page-Auszug realisieren. Aber wie gesagt, man kann natürlich alles mögliche anstellen, aber es geht auch ohne jegliches Heckmeck und Kopfstand-und-mit-den-Zehen-wackeln und ohne irgendwelchen Dirty-Hack-Scripte einfach dadurch, dass man den Schnittstellen-Job schlichtweg via systemd-service-Unit starten und beenden lässt. Darüber nachzudenken, wie man auf einem systemd-system Dinge ohne systemd tun kann, scheint mir einigermaßen kontraproduktiv zu sein.

    jm2c

  • Hallo

    habe mir mal systemd und in dem Zusammenhang Units sind angelesen.

    Also noch mal zu Erklärung was ich habe und später was ich will.

    Habe:

    - Einen Raspi der entweder keinen Graphischen Ausgang benutzt oder auf dem Kodi läuft (2 unterschiedliche Fälle).

    - Dazu eine USV in Form einer Powerbank und einen Arduino der das ganze kontrolliert. Der Arduino kann dem PI auch per Relais den Saft abdrehen.

    - Der Arduino kommuniziert per RS232 mit dem Raspi. Das der Arduino den Raspi herunterfährt, 2-3min wartet und dann den PI stromlos macht, läuft schon.

    Will:

    Eine Möglichkeit, mit zu bekommen, wenn der Raspi vom Benutzer heruntergefahren wird, also vom/im Rapsi und der Befehl nicht vom Arduino kommt. Und ich will UNTERSCHEIDEN ob es ein reboot ist oder ein shutdown ist. Weil bei einem reboot soll der Arduino nichts machen und bei einem shutdown, warten und dann den Strom abschalten.

    Ich wusste das das System einen shutdown quasi per sigterm verkündet wird und hoffte/hoffe das es auch eine Möglichkeit gibt zu unterscheiden ob es ein richtiger shutdown ist oder ein reboot.

    Kennt jemand einen Weg in Python ein reboot von einem shutwon zu unterscheiden?

  • Kennt jemand einen Weg in Python ein reboot von einem shutwon zu unterscheiden?

    Eine mögliche Lösung hat rpi444 doch in #44 aufgezeigt. Was stimmt damit nicht? Hast Du das ausgetestet? Mit welchem Ergebnis?

  • Konkret für dein vorhaben, ohne Unterscheidung von reboot zu shutdown:

    Warum sagst du nicht einfach, wenn nach Zeit x keine Kommunikation auf der UART Schnittstelle stattgefunden hat kann der Arduino stromlos machen.

    Oder wenn auf GPIO x so und so lang kein Pegelwechsel (oder GPIO ist so und so lange auf LOW (sollte aber gestestet werden wie sich das verhält wenn der PI ausgeschalten ist) mehr stattgefunden hat kann der Arduiono stromlos machen.

    So würd ichs wohl lösen.

  • Ich habs jetzt spasseshalber einfach mal mit 2 passenden Service-Units und dem Log-Script getestet... und es funktioniert genau wie erwünscht.

    /etc/systemd/system/start-before-reboot.service

    Code
    [Unit]
    Description=thlu:start-before-reboot.service: Start at reboot
    DefaultDependencies=no
    Before=reboot.target
    [Service]
    Type=oneshot
    ExecStart=/usr/local/bin/create-journal-entry "reboot"
    [Install]
    RequiredBy=reboot.target

    /etc/systemd/system/start-before-shutdown.service

    Code
    [Unit]
    Description=thlu:start-before-shutdown.service: Start at shutdown
    DefaultDependencies=no
    Before=shutdown.target
    [Service]
    Type=oneshot
    ExecStart=/usr/local/bin/create-journal-entry "shutdown"
    [Install]
    RequiredBy=shutdown.target

    Der erste Versuch war ein Reboot, der zweite ein Poweroff. Das sind die Journaleinträge:

    Code
    # journalctl -b -2 | grep thlu | grep journal
    Nov 09 18:28:19 thomaspc thlu:create-journal-entry[3315]: User=, Parm1=reboot Parm2= Parm3=
    Nov 09 18:28:19 thomaspc thlu:create-journal-entry[3317]: User=, Parm1=shutdown Parm2= Parm3=
    
    # journalctl -b -1 | grep thlu | grep journal
    Nov 09 18:29:40 thomaspc thlu:create-journal-entry[3093]: User=, Parm1=shutdown Parm2= Parm3=

    Das ein Reboot natürlich den Shutdown implizit enthält, ist ja klar. Aber trotzdem, damit ist das Problem auf sauberste Weise mit einfachsten Boardmitteln gelöst.... wie schon auf Seite 1 in meinem erten Posting erwähnt. Statt des Journaleintrags wäre jetzt hier nur die kurze Kommunikation mit dem eigentlich Prozess vorzusehen. Fertig.....

    Ich lese jetzt hier nur noch mit.... für Probleme um des Problems willen ist mir Zeit eigentlich zu schade.

Jetzt mitmachen!

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