Unable to access the X Display

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,
    ich hoffe mal auf euer hilfe, und vielen danke erstmal.

    zu meinem Problem, ich habe einen Raspi Model B, Raspbain Linux 7 Aktuelle Version.
    als Display nutze ich das pollin.de 7 zoll touchscreen Display, angeschlossen am Pi über HDMI
    Display:
    http://www.pollin.de/shop/dt/NTMwOT…I_VGA_CVBS.html

    möchte gerne ein Python Script ausführen bekomme aber immer die Fehlermeldung :

    sudo python launchPhotoBooth.py
    ./photoBoothPiNew.py:51: RuntimeWarning: This channel is already in use, continuing anyway. Use RPIO.setwarnings(False) to disable warnings.
    GPIO.setup(GPIO_FLASH_PIN,GPIO.OUT)
    numid=3,iface=MIXER,name='PCM Playback Route'
    ; type=INTEGER,access=rw------,values=1,min=0,max=2,step=0
    : values=2
    Unable to access the X Display, is $DISPLAY set properly?

    da ich ziemlicher python anfänger bin hoff ich auf euch.

    ich kann das Script lokal und auch über ssh nicht starten immer die selbe X Display Fehlermeldung.

    wo kann ich ansetzen um den fehler zu beheben ?

    Raspbain mit startx zu starten ist weder local noch per ssh ein problem und funkt. bestens.

    ich starte das Programm mit "sudo python aunchPhotoBooth.py"

    bei dem script handelt es sich um ein PhotoBooth Script das ich aus Github gezogen habe, die version die ich zum testen verwende ist als zip mit dabei.

    vielen dank

  • Hallo snuffy80,

    bedeutend ist die Meldung "Unable to access the X Display, is $DISPLAY set properly?"
    Das bedeutet, daß das Programm nicht weiß, auf welchem Display es ausgeben soll.

    Hast Du X gestartet ? Das wäre erstmal die Voraussetzung!

    Ich gehe mal davon aus, daß es so ist. Normalerweise solltest Du das Programm mit dem User starten, zu dem auch die X-Oberfläche gehört - dann sollte es keine Probleme geben.

    Wenn Du es mit "sudo" startest, läuft es aber als "root". Was hat das für einen Grund? Starte es mal ohne "sudo".

    Gruß, mmi

  • Hallo mmi,

    danke für diesen tipp,...

    mein forgehen, ich habe startx ausgeführt und unter LXTerminal mit sudo ./launch...py
    zum laufen gebracht, jetzt sieht alles noch ein wenig komisch aus aber ich werde mal weiter versuchen . wenn ich darf werd ich sicher noch fragen haben :)

    vielen dank

    Philipp

    Einmal editiert, zuletzt von snuffy80 (25. Mai 2014 um 23:40)


  • mein forgehen, ich habe startx ausgeführt und unter LXTerminal mit sudo ./launch...py
    zum laufen gebracht,

    Ich vermute mal, dass der Grund dafür, dass DISPLAY ungesetzt ist, genau darin liegt, dass das Skript via sudo gestartet wird.

    (Meine Güte, jetzt habe ich tatsächlich einen Satz fabriziert, in dem dreimal die Konjunktion dass vorkommt:X)

    Das Standardverhalten bei sudoers Regeln, bei denen das nicht explizit davon abweichend vorgegeben wurde, ist nämlich,
    dass die Umgebung des auszuführenden sudo Kommandos bis auf ganz wenige Umgebungsvariablen eingestampft wird
    (was meist im Sinne einer höheren Systemsicherheit ist);
    oder, um aus man sudoers zu zitieren

    Da es oben heisst, The DISPLAY, PATH and TERM variables remain unchanged,
    wäre eine Möglichkeit, dass Du Deinem sudo Kommando die Option für ein login shell behaviour,
    also "-i" mitgibst.

    Da man das aber auch nicht immer unbedingt will
    (schliesslich werden dann die .bash_profile sowie die .bashrc im HOME des users, unter dem das sudo Kommando ausgeführt wird - also meist die von root - gesourced),
    sehe ich die sauberere Lösung darin, in Deiner sudoers Datei in den Defaults Deines Users, der das sudo Kommando mit anderen (meist höheren) Rechten ausführt,
    die Umgebungsvariable DISPLAY in die env_keep Liste aufzunehmen.

    Dazu editierst Du die sudoers, indem Du in eine root Shell wechselst und dort das Kommando visudo eingibst.
    Das setzt ein Lock auf diese sensible sudoers Datei und lädt sie in den Editor,
    der auf Unix Systemen meist der vi ist.

    Ich weiss, dass mancher mit dem vi auf Kriegsfuss steht, und üblicherweise kann man durch Setzen der Umgebungsvariablen EDITOR bzw. VISUAL dafür sorgen,
    dass ein Editor seiner Wahl aufgerufen wird.
    Weil sudo aber so ein sicherheitskritisches Kommando ist, ist gemeinerweise nicht selten der vi während des Builds auch des Hilfskommandos visudo
    als Standardeditor fest einkompiliert worden.
    Deshalb kann es sein, dass visudo die Umgebungsvariablen EDITOR bzw. VISUAL schlicht ignoriert.
    Am besten einfach ausprobieren, also z.B.

    Code
    # EDITOR=nano visudo


    aufrufen. Evtl. klappt es auch mit einem anderen Editor.
    Ansonsten wäre jetzt erstmal ein Zehn-Minuten-Kurztutorial zum vi angesagt.

    Wenn die sudoers (in welchem Editor auch immer) geladen ist,
    such Zeilen, die mit Defaults beginnen, wovon es meist mehrere gibt.
    Evtl. existiert ja bereits eine Defaults Zeile für den User, der Dein sudo Kommando absetzen können soll.
    Ich nehme mal an, dass dieser User pi sei.
    Für den könntest Du z.B. folgende Defaults Zeile in die sudoers schreiben bzw. eine bereits vorhandene entsprechend ergänzen:

    Code
    Defaults:pi  env_keep+="DISPLAY"

    Wenn man nun aus dem Editor mit Abspeichern der Änderungen des Buffers aussteigt
    (im vi wäre das die Tastenfolge, Esc :wq<enter>)
    nimmt visudoer zuvor einen Syntaxcheck der sudoers vor, was sehr praktisch ist.
    Sollte irgendeine Editierung der sudoers Syntax zuwiderlaufen, weist visudo unter Angabe der Zeile darauf hin,
    wo es ein Problem vermutet und fragt, what now?.
    Wenn man hier nochmal ein e eingibt und mit <enter> bestätigt,
    springt der Editorprompt in die strittige Zeile und man hat Gelegenheit die Syntax zu korrigieren.

    Zum Schluss kann man mit z.B.

    Code
    # sudo -lU pi|grep env_keep.*DISPLAY


    gucken, ob dem User seine DISPLAY Variable für seine sudo Kommandos erhalten bleibt.

    Anschliessend (hoffe ich) sollte das sudo Kommando zumindest nicht mehr mit einem,
    unset DISPLAY error abbrechen.

    Einmal editiert, zuletzt von Life_of_Pi (26. Mai 2014 um 00:59)

  • Vielen danke für eure Hilfe :) ich hab jetzt mein script mal zum laufen gebracht :)

    für mich stellt sich jetzt noch die frage wie ich das automatisch starten kann ?
    eventuell in der rc.local oder so ?

    die Manuele Start Situation sieht im moment so aus :

    RPi Starten --> als Pi User anmelden --> startx --> LXTerminal öffnen --> cd /xxx -->
    und dann mit # sudo ./launchPhotoBooth.py das ganze starten.

    gibt es eine möglichkeit das automatisch zu machen ?

    vielen dank

    Einmal editiert, zuletzt von snuffy80 (28. Mai 2014 um 01:14)

  • Fasse die einzelnen Schritte zu einem Shell Script zusammen.
    Das ist der übliche erste Schritt zur Automatisierung und nebenbei auch gleich zu einer gewissen Dokumentierung (die einzelnen Befehle hat man das nächste Mal oft wieder vergessen).

    Wenn alles in 1-3 Zeilen passt, kann man dafür auch ein Shell Alias oder eine Shell Function definieren
    und diese Definition in z.B. seine $HOME/.bashrc packen (wenn Bash die eigene Login Shell ist).

    Wenn es aufwendiger wird, entweder mehr als etwa 50-100 Codezeilen oder sehr viele Schleifeniterationen,
    in deren Bodies viele oder CPU-zeitfressende externe Aufrufe erfolgen,
    sollte man darüber nachdenken, das in einer dynamischen Skriptsprache zu schreiben (z.B. Python, Perl, Ruby),
    dabei aber nach Möglichkeit "in dieser Sprache bleiben", also [i]system(), subprocess(), pipe()[i] u.ä. externe Aufrufe vermeiden.

    Wenn das immer noch zu inperformant ist (was aber auch sehr am Coding liegen kann),
    dann auf eine Compiler-Sprache (z.B. C) zurückgreifen.

    Einmal editiert, zuletzt von Life_of_Pi (28. Mai 2014 um 12:28)

Jetzt mitmachen!

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