eConsoleAppContainer kill

  • irgendwie scheint sich der eConsoleAppContainer nicht so zu verhalten, wie ich das erwarten wuerde :smiling_face:

    habe hier gelesen, dass man zum abbrechen eines mit container.execute(<cmd>) gestarteten prozesses container.kill() nehmen soll.

    das scheint auch auf den ersten blick zu funktionieren, aber

    - in der class reference von eConsoleAppContainer gibt es nur init und execute... kein kill???

    - wenn ich container.execute(), container.kill(), container.execute(), etc. mehrfach hintereinander aufrufe, dann bleiben zum einen zombie prozesse und zum anderen scheinen auch prozesse zu ueberleben.

    wenn ich statt container.kill() ein os.system("killall -9 <cmd>) verwende, dann funktioniert's.

    wie verwende ich eConsoleAppContainer richtig?

    danke.

  • .kill() gibt es definitiv im eConsoleAppContainer.

    Sonst würdest du ja einen GS bekommen :winking_face:

    Es ist ja nicht alles als def …() hinterlegt.


    für die One (master) in Zeile 284:

    http://git.opendreambox.org/?p…hb=refs/heads/master#l280


    u.a. für die 9x0 (4.3) in Zeile 388:

    http://git.opendreambox.org/?p…29f6d5576b31202425e7#l384


    Vielleicht ist das auch ein Timing-Problem, wenn du zu schnell .kill und .execute ausführst.

    Evtl. verschluckt sich da was.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • danke Sven H ... hmm, da gibt's ja noch ne menge anderer funktionen, die nicht in der class reference sind. scheint so, als wuerden in der class reference nur die in python implementierten funktionen aufgelistet.


    anyway, habe mal einen eigenen einfachen ConsoleAppContainer implementiert... und der funktioinert so, wie ich mir das vorgestellt hatte...

    • Offizieller Beitrag

    Das Problem an Popen, system ... usw. ist, dass der gesamte RAM gecloned wird wenn du einen subprocess startest.. und das heißt, dass du einen mega RAM verbrauch hast.


    Und es durchaus öfter vorkommen kann, dass dann e2 einfach gekillt wird, weil nicht genug RAM vorhanden ist.


    Dies ist bei unserem container nicht so. Das ist auch der Grund wieso es den überhaupt gibt.


    Okay.. es war bei den älteren Boxen schlimmer. Aber auch bei den neueren wirst du garantiert Probleme bekommen.


    Abgesehen davon würde mich interessieren, was du da genau machst...


    cu

  • gerne, ich mache folgendes:

    in meiner diashow mit bildern, videos und hintergrundmusik starte ich damit die hintergrundmusik und die videos:

    Code
            url = "'file://%s'" % filename
            cmd = 'gst-launch-1.0 playbin -v uri=' + url
            if self.song_list:
                cmd += ' flags=0x51'
            self.video_container.execute(cmd)
    Code
            url = "'file://%s'" % filename
            cmd = "gst-launch-1.0 playbin uri=" + url + " audio-sink='alsasink'"
            self.audio_container.execute(cmd)

    und bei einem abbruch kille ich die container mit self.xxxxx_container.kill()


    solange ich das audio file nur einmal gestartet habe, funktioniert das auch. aber sobald ein audio file abgelaufen ist und ich das zweite starte, dann die diashow abbreche und den tv-service starte, habe ich gemischten ton vom zweiten audio file und tv-service. das kill scheint dann nicht zu funktionieren.

  • Man könnte auch sendCtrlC() nehmen. Kannst ja davor und danach ein getPID() machen. Dann siehst du, ob die weg ist oder nicht.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

    • Offizieller Beitrag

    Abgesehen davon, dass ich die Geschichte mit gst-launch schon sehr abenteuerlich finde... und eher china tauglich, ist container.kill wirklich der harte weg... wie ein kill -9 ... besser wäre in der tat container.sendCtrlC()... und dann warten bis appClosed ausgelöst wird.


    Das muss danach noch kommen.


    cu

  • besser wäre in der tat container.sendCtrlC()

    ja, aber am ende zaehlt doch das resultat... und killall -9 ... funktioniert doch immer todsicher :winking_face:

    ich hatte mal problehalber das container.kill gegen ein os.system("killall -9 gst-bla") ersetzt... und damit gings.

  • Eben nicht. Bei Programmierung geht es darum, etwas so sauber wie möglich zu implementieren.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • was waere sauber?

    - sendctrlc

    - warten auf beenden... wie lange? also brauche ich einen timer

    - falls sich der prozess nicht in der zeit von selbst beendet, dann kill()

    - und wenn das nicht hilft, noch ein killall -9 hinterher?


    sendctrlc ist sicher sinnvoll, wenn der prozess noch irgendwelche dinge abschliessen muss... gecachte daten auf die platte oder so.

    aber in diesem fall geht es doch nur darum, den prozess zu killen.

  • Steht doch schon oben, dass du auf appClosed warten sollst. Du brauchst du sicher keinen Timer für.


    Stell dir einfach mal vor, enigma2 wäre so programmiert, wie du es vorlebst. Aber das mit sauber programmieren hab ich dir ja schon diverse Male gesagt.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • bei dem appClosed legst du vorher fest, welche def ausgeführt wird, wenn der Container fertig ist.

    Code
    self.container = eConsoleAppContainer()
    self.appClosed_conn = self.container.appClosed.connect(self.afterAppClosed)
    ...

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • das verstehe ich doch... aber ist denn sicher, dass sich der prozess mit sendctrlc sicher beendet und appclosed aufgerufen wird? wenn das kill schon nicht funktioniert, warum dann sendctrlc?

  • Was machst du denn, wenn das Audio File zu Ende ist und du ein neues startest, benutzt den den gleichen self.audio_container?

    MacDisein, die frage ist nicht schlecht und hat mich angeregt, mal auszuprobieren, was passiert, wenn ich jedes mal einen neuen eConsoleContainer instanziiere... und siehe da, es funktioniert. (in meiner console implementierung wird naemlich auch jedes mal ein neuer subprozess erzeugt).

    ein memory leak sollte ja dadurch nicht entstehen, da die freigegebenen instanzen von der garbage collection wieder entsorgt werden muessten.

  • so sieht jetzt mein workaround fuer das nicht (immer) funktionierende kill aus: