python script via rc.local -> stderr-Umleitung funzt nicht

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Also das Speicherproblem hatte ich jetzt 1mal mit Nachweis, als mpd noch via subprocess(mpc) angesprochen wurde. Das kam nach ca. 2-3 Monaten Laufzeit. Aktuell steuere ich mpd über MPD2_python, welches jetzt 2mal nach wenigen Tagen gecrasht ist, ich jedoch noch keine Fehlermeldung ermitteln konnte, weil:

    1. Ich nachts kurz aufgewacht bin, gesehen habe, dass der Wecker tot ist, und ihn dann einfach schnell rebootet habe, um weiterschlafen zu können

    2. Ich die Umleitung von stderr so blöd gemacht habe, dass der Errorlog beim Reboot überschrieben wurde.

    Aktuell muss ich also auf den nächsten Crash warten, in der Hoffnung, dass dann was brauchbares im Errorlog steht.

    Mit vmstat ohne Optionen sehe ich ja u.a. den aktuell freie Speicher. Das könnte ich zyklisch (halbe Stunde) aufrufen und die Ausgabe in ne Datei schreiben.

    Wie ps mir weiterhelfen kann, ist mir nicht ganz klar.

    Ich sehe aber nicht, wie mich das overcommit_memory weiterbringen soll. Wenn ich mit vmstat regelmäßig den freien Speicher mitlogge und der immer weiter schrumpft, dann weiß ich, dass es irgendwo ein memory leak gibt.

    Wenn ich trotz massig freiem Speicher einen

    OSError: [Errno 12] Cannot allocate memory

    bekomme, dann könnte mir das overcommit_memory helfen, die Ursache würde ich damit aber nicht beheben.

    Mein Problem ist, dass ich immer sehr lange warten muss, um den nächsten Schritt machen zu können und da ist ne Punktlandung anzustreben.

    Michael

  • python script via rc.local -> stderr-Umleitung funzt nicht? Schau mal ob du hier fündig wirst!

  • in dem aber nicht drin steht warum es gecrasht ist. Immer diese Mär vom übermächtigen logging von journald.

    a) hat ersteres keiner behaupten und b) hat letzteres auch keiner behauptet. Also wie du auch immer darauf kommst... Das Logging ist in dem Kontext praktisch, dass man sieht, wann das Skript gecrasht ist und wieder gestartet wurde.

    Zitat

    Den Eintrag einer Zeile in einer Datei gegenüber einer Systemd ServiceUnit als umständlich zu beschreiben ist doch etwas realitätsfremd.

    dbv: Du musst schon alles betrachten, nicht nur einen Teilaspekt. Der TE hat sich _zusätzlich_ einen Watchdog programmiert. Das ist umständlich. Nicht nur, weil systemd das ootb kann, sondern weil es auch schon vorher Lösungen (wie supervisord) gab, die das überflüssig machen.

    Das du systemd nicht magst ist ja hinlänglich bekannt. Aber mit welche kurzsichtigen Unsachlichkeit du dagegen wetterst ist schon bedenklich. Selbst für jemanden, der sich als "Ewig-Gestriger" bezeichnet.

    Gruß, noisefloor

  • naja ... zum Filtern und für Details ist das schon nützlich ( -> https://linux.die.net/man/1/ps )

    Muss ich mal mit spielen. Ohne Optionen aufgerufen, kommt nichts brauchbares :)

    Der TE hat sich _zusätzlich_ einen Watchdog programmiert. Das ist umständlich.

    Jedenfalls gings schneller, als sich in systemd einzuarbeiten:

  • Habe jetzt übrigens den ersten Crash mit Log:

    Tja, subprocess hat ein Speicherproblem und mpd2_python ein Netzwerkproblem.

    Hmm, vielleicht mache ich das dann über das Netzwerk einfach zu Fuß. Lerne ich was dabei und kann mir ein vernünftiges Fehlerhandling ausdenken. Ist für meine drei Zugriffe vermutlich nicht sonderlich komplex.

  • > self.client.connect("localhost",6600)

    Dann wuerde ich mal mit netstat anzeigen lassen wie viele Verbindungen es zu diesem Port gibt (und ob der Daemon es noch offen hat)

    Bei localhost wird es wohl nicht viel helfen, aber ein Versuch mit try ... catch, ein bisschen warten und ein neuer Versuch waere die uebliche Vorgehensweise.

  • Ich hab das jetzt zu Fuß gemacht und so umgesetzt:

    Vielleicht nicht super elegant.

    Aber die Funktion versucht nun 3mal in Folge das Kommando an mpd loszuwerden. Wenn es 3mal in Folge schief geht, dann wird eine Exception geworfen.

    Klappt es beim 2. oder 3. Versuch, gibt es trotzdem Einträge im Logfile.

    Mal gespannt ...

    Michael

    Einmal editiert, zuletzt von astirfreak (28. Oktober 2018 um 11:17)

Jetzt mitmachen!

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