PI3 schläft ein? eine Verständnisfrage

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo,
    ich habe ein Python3-Script, das nach bestimmten Uhrzeiten eine Steckdose ein- bzw. ausschaltet.
    Das script wird mit @reload im crontab gestartet.
    Es prüft die Uhrzeit, schaltet danach die (Funk)Steckdose ein, bzw aus und legt sich danach für eine Minute schlafen um dann die while-Schleife erneut abzuarbeiten.
    OS ist Raspbian.

    Das funktioniert auch die ersten Stunden sehr gut. Lediglich nach ein paar Stunden werden keine Aktivitäten mehr ausgeführt. Der pi3 läuft aber noch und ich kann andere Prozesse ausführen, nur dieser Prozess reagiert nicht mehr, obwohl er noch vorhanden ist. WLAN ist nicht im Spiel.

    Gibt es so etwas wie einen "Schalfmodus" für Prozesse, der nach einiger Zeit aktiviert wird, oder hat jemand eine andere Erklärung?
    Herzlichen Dank.


    P.S. ich habe jetzt die Schleife herausgenommen und starte das Script über crontab jede Minute, trotzdem würde mich der Grund für das o.a. Verhalten interessieren.

    Gruß
    Rainer

    Gruß
    Rainer

    Einmal editiert, zuletzt von Borbecker (7. Dezember 2016 um 08:59)

  • Poste mal den Code, sofern nichts privat/geheimes dabei ist was du nicht teilen willst. Bevor du tiefer ins System gehst würde ich mal alle "Zähler" in deinem Programm prüfen. Eventuell gibt es da einen Überlauf oder etwas ähnliches, weshalb dann dein Programm ewig läuft.

  • Danke für die Mühe.
    Hier ist es(schlicht und einfach) ;) :


    Gruß
    Rainer

    Einmal editiert, zuletzt von Borbecker (7. Dezember 2016 um 11:18)

  • Ich diskutiere gerade parallel ein ähnliches Thema. Was macht denn dein os.system-call? Kannst du den mal auskommentieren, und zB stattdessen einen timestamp in einer Datei updaten? Wenn das *nicht* unter der selben Problematik leidet, dann haben wir das Problem schon mal etwas mehr eingegrenzt.

    Ein genereller Mechanismus hinter diesem Verhalten waere mir nicht bekannt. Du könntest auch mal mit den üblichen Verdächtigen - top, htop, ps, etc. - versuchen rauszufinden, Ob der Prozess irgendwie ungebührlich in Speicherbedarf oder anderen Dingen wächst.

  • Wieso? Du hast doch schon os.system-calls, stattdessen musst du doch einfach nur eine Datei "anfassen" und was reinschreiben?

    Code
    import datetime
    ...
    with open("/tmp/running-test", "w") as outf:
           outf.write(datetime.datetime.now().isoformat())

    Hat auch nix mit Unix, sondern mit programmieren in Python zu tun.

  • Vermutlich liegt der Fehler irgendwo bei der Zeiterkennung.
    Ich versuche mal eine Log anlegen zu lassen... Leider bin ich nicht so fitt in Python.
    Könnte jemand meine Zeilen prüfen? Welches format hat lt? Habs jetzt mal als String gesehen... ist bestimmt n.i.O. :(
    Müsste wahrscheinlich als Array punkt für punkt geschrieben werden, oder kann man ein Array in Python komplett schreiben?


    Das Programm sollte jetzt bei jedem auslösen der while()-Schleife in die Log.txt schreiben.
    Format:
    Localtime: WERT /tab h: WERT / tab m: /newline

  • Wichtig: cr4nk schreibt nur einen Timestamp, hat aber immer noch die os.system calls drin. Aus Gruenden der Problemseparation halte ich das fuer falsch. Nur timestamp schreiben, und keine anderen Seiteneffekte auslösen entkoppelt das Problem von einem Verhalten, dass auch im anderen Thread hier beschrieben wird - dass das arbeiten mit den GPIOs Probleme macht.

  • Nunja ich will einfach nur loggen, wann er das letzte mal durch die Schleife geht bzw. vielleicht geht er weiterhin durch die Schleife und geht nicht in die if()s. Dafür müsste man einfach nochmal in jedem if() kurz etwas in die Log schreiben. Dann sehen wir auf einfache weise, was das Programm nicht mehr macht. Das würde ich ein paar mal wiederholen und dann schauen ob es immer an der selben Stelle aussteigt.

    Einmal editiert, zuletzt von cr4nk (7. Dezember 2016 um 14:55)

  • Wenn man das tun möchte, sollte man besser das Modul logging benutzen:


    Automatisch zusammengefügt:
    Und ich halte es fuer weniger günstig, weil es sehr wahrscheinlich ist, dass das os.system der Widerporst ist. Der andere Kram hat dafür IMHO nicht das Potential.

  • Hallo zusammen,

    alle Betriebssysteme können nahezu beliebig viele Dateien geöffnet haben. Bei den meisten Programmiersprachen, die ich kennengelernt habe, ist diese Anzahl drastisch reduziert.

    Ich sehe in dem Code, dass eine Datei geöffnet wird und das Daten hineingeschrieben werden. Aber vom Datei-Schließen sehe ich hier nichts. Somit erhöht sich der Zähler offener Dateien - bis es irgendwann knallt (auf Basis der Programmiersprache bzw. des Betriebssystems, je nach dem, wessen Grenze zuerst erreicht ist), nichts mehr geöffnet werden kann...

    Ist das in Python alles anders?

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (7. Dezember 2016 um 22:44)

  • Andreas: Im originalen Code (aus Beitrag #3) sehe ich nicht, daß Dateien geöffnet würden. Das Ursprungsproblem kann also eigentlich nicht damit zusammenhängen. In den anderen Codebeispielen sorgt das "with"-Konstrukt dafür, daß die Dateien wieder ordnungsgemäß geschlossen werden.

  • Hi,

    Das Problem liegt bestimmt am sudo. ;)

    sudo fragt standardmäßig nach einer gewissen Zeit erneut dem root Passwort. Wenn es das nicht bekommt kann es das Programm nicht mehr starten weil zu wenig Rechte.

    Nimm die zwei sudos aus dem Skript und starte das Skript selber mit sudo.

    DON'T PANIC!

  • joh.raspi bezweifele ich. crontab ist root, und *wenn* das ein Problem waere, weil sudo im Passwort-Prompt steht - dann klappt's gar nicht, nicht erst nach Stunden nicht mehr.

  • joh.raspi bezweifele ich. crontab ist root, und *wenn* das ein Problem waere, weil sudo im Passwort-Prompt steht - dann klappt's gar nicht, nicht erst nach Stunden nicht mehr.

    Nein, gleich mehrere Irrtümer. cron ist nur dann root, wenn Du auch die root-Crontab verwendest. Verwendest Du die User-Crontab spielt der Password-Keep sehr wohl eine Rolle. Das heisst, beim manuellen starten klappt es, beim nächsten Start ausserhalb des Password-Keep failed der Job. Mein Vorschreiber hat unbedingt Recht: In eine User-crontab gehört kein sudo rein! Entweder Du nutzt die root-crontab oder Du berechtigst das Script über die Policies mit root-Rechen laufen zu dürfen, wenn du die User-crontab weiterhin nutzen möchtest. In beiden Fällen ist "sudo" nicht nur unnötig , sondern geradezu eine Fehlerquelle.

    Einmal editiert, zuletzt von WinterUnit16246 (7. Dezember 2016 um 18:54)

  • @ThomasL da das Skript nach Neustart läuft, ist davon auszugehen, dass es in der root/Systemcrontab läuft. Womit sich die Frage (weiterhin) stellt, *warum* es damit aufhört. Du orakelst davon, dass sudo eine Fehlerquelle sei, wenn man es wie hier unnötig verwendet. Das kann ich nicht beurteilen - hast du eine konkrete Erlaeuterung? Oder ist das eine allgemeine Aussage, weil man etwas tut, das man nicht tun sollte, und es zB beim Aufruf als nicht-root Seiteneffekte hat?

Jetzt mitmachen!

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