Java Nie można połączyć się z serwerem okien X11 przy użyciu „localhost: 10.0” jako wartości zmiennej DISPLAY

Mam skrypt używający javy do łączenia się z X11 w porcie 10.0 na localhost

ale zawsze otrzymuję ten błąd

java.lang.InternalError: Can't connect to X11 window server using 'localhost:10.0' as the value of the DISPLAY variable.
    at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
    at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:62)
    at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:178)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:142)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:186)
    at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)
    at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:112)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:186)
    at java.awt.Toolkit$2.run(Toolkit.java:849)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:841)
    at ij.io.Opener.openJpegOrGif(Opener.java:367)
    at ij.io.Opener.openImage(Opener.java:220)
    at ij.io.Opener.openImage(Opener.java:249)
    at ij.io.Opener.open(Opener.java:116)
    at ij.IJ.open(IJ.java:1112)
    at ij.macro.Functions.open(Functions.java:2006)
    at ij.macro.Functions.doFunction(Functions.java:129)
    at ij.macro.Interpreter.doStatement(Interpreter.java:205)
    at ij.macro.Interpreter.doBlock(Interpreter.java:515)
    at ij.macro.Interpreter.runUserFunction(Interpreter.java:278)
    at ij.macro.Interpreter.getFactor(Interpreter.java:1200)
    at ij.macro.Interpreter.getTerm(Interpreter.java:1162)
    at ij.macro.Interpreter.getExpression(Interpreter.java:1145)
    at ij.macro.Interpreter.getBooleanExpression(Interpreter.java:881)
    at ij.macro.Interpreter.getLogicalExpression(Interpreter.java:857)
    at ij.macro.Interpreter.getBoolean(Interpreter.java:850)
    at ij.macro.Interpreter.doIf(Interpreter.java:829)
    at ij.macro.Interpreter.doStatement(Interpreter.java:217)
    at ij.macro.Interpreter.doBlock(Interpreter.java:515)
    at ij.macro.Interpreter.doStatement(Interpreter.java:241)
    at ij.macro.Interpreter.doIf(Interpreter.java:831)
    at ij.macro.Interpreter.doStatement(Interpreter.java:217)
    at ij.macro.Interpreter.doStatements(Interpreter.java:195)
    at ij.macro.Interpreter.run(Interpreter.java:99)
    at ij.macro.Interpreter.run(Interpreter.java:65)
    at ij.macro.Interpreter.run(Interpreter.java:75)
    at ij.plugin.Macro_Runner.runMacro(Macro_Runner.java:127)
    at ij.plugin.Macro_Runner.runMacroFile(Macro_Runner.java:112)
    at ij.IJ.runMacroFile(IJ.java:103)
    at ij.ImageJ.main(ImageJ.java:517)

Próbowałem wszystkiego, aby rozwiązać ten problem, takich jak:

export DISPLAY=:10.0
export DISPLAY=localhost:10.0

Próbowałem też portu 0.0, ale zawsze otrzymuję ten sam błąd

po wypróbowaniu xhost

xhost +local:all
xhost:  unable to open display ""
xhost:  unable to open display ":10.0"

jak mogę to naprawić Pomyślałem, że serwer X nie działa, więc próbowałem startxpowiedzieć, że działa na tym porcie

mój system to Ubuntu Server Edition 10.04

To polecenie pomogło mi rozwiązać problem:

export DISPLAY=:0

Musisz określić -Djava.awt.headless=trueparametr podczas uruchamiania.

Usuń zmienną DISPLAY

unset DISPLAY

Pomaga to w większości przypadków (np. Uruchamianie serwerów aplikacji lub innych narzędzi opartych na Javie) i pozwala uniknąć modyfikowania wielu wierszy poleceń.

Wygodne może być również dodanie go do .bash_profile dla dedykowanego użytkownika serwera aplikacji / narzędzi.

Myślę, że pracujesz w trybie sudo, przejdź do trybu użytkownika i spróbuj ponownie

W przypadku, gdy ktoś próbuje uruchomić automatyczne testy jednostkowe za pośrednictwem wtyczki maven-surefire-plugin na CI (jenkins, ..) i otrzyma powyższy błąd, pamiętaj o zaktualizowaniu konfiguracji wtyczki surefire:

<plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-surefire-plugin</artifactId>
     <version>${maven-surefire-plugin.version}</version>
     <configuration>
            <systemPropertyVariables>
                <java.awt.headless>true</java.awt.headless>
            </systemPropertyVariables>
      </configuration>
</plugin>

To naprawi to:

/usr/bin/java -Djava.awt.headless=true $Your_program

U mnie logowanie jako -Y zamiast -X zadziałało.

Jeśli masz niezaufane X11, jak pokazano poniżej, spróbuj zamiast tego flagi -Y (jeśli ufasz hostowi):

Ostrzeżenie : niezaufana konfiguracja przekazywania X11 nie powiodła się: dane klucza xauth nie zostały wygenerowane

Po kilku dniach daremnego wysiłku instalowania szklistego rybka na malinowym pi 2 z bezgłową fedorą 22, poniżej zadziałało dla mnie bez problemu

 unset DISPLAY
java -Djava.awt.headless=true -jar glassfissh-installer-v2ur2-b04-linux.jar

tutaj moja pomoc

Po pierwsze: uruchom XQuartz

Po drugie: ssh -X user @ ip_address

...: rozpocznij proces

jeśli ssh, a następnie uruchomisz XQuartz, otrzymasz ten błąd

To rozwiązało mój problem

xhost +

ale pamiętaj, że xhost +całkowicie dezaktywuje uwierzytelnianie i umożliwia każdemu dostęp do wszystkich aplikacji na ekranie.

xhost +si:localuser:root wydaje się działać podobnie z odpowiednim uwierzytelnieniem.

Najpierw zrób to w fazie kompilacji Jenkinsa, jeśli używasz lub ustawisz w / etc / profile:

unset DISPLAY
export DISPLAY=:0

następnie ustaw tę właściwość w kodzie java lub za pomocą maven: -Djava.awt.headless = false

Używałem Xming i otrzymałem podobny błąd. Podjęto następujące kroki, aby rozwiązać problem:

1. W uruchomieniu Xming zaznacz pole bez kontroli dostępu.
2. W szpachli uruchomiono następujące polecenie: DISPLAY=XXX.XXX.XXX.XX:0.0; export DISPLAY

Zastąp XXX.XXX.XXX.XXswoim adresem IP.

Rozwiązany. Po prostu wylogowuję się i loguję przez xorg!

Jeśli próbujesz wyeksportować ekran za pomocą su i nadal nie działa. To właśnie zadziałało dla mnie. Wypróbuj przekierowanie X11 dla użytkowników sudo.

Połącz zdalny host za pomocą opcji -X z ssh.

# ssh -X root@remote-host

Teraz wypisz zestaw coockie dla bieżącego użytkownika.

# xauth list $DISPLAY
    node01.thegeekdiary.com/unix:10  MIT-MAGIC-COOKIE-1  dacbc5765ec54a1d7115a172147866aa
# echo $DSIPLAY
    localhost:10.0

Przełącz się na inne konto użytkownika za pomocą sudo. Dodaj plik cookie z wyjścia polecenia powyżej do użytkownika sudo.

# sudo su - [user]
# xauth add node01.thegeekdiary.com/unix:10  MIT-MAGIC-COOKIE-1  dacbc5765ec54a1d7115a172147866aa

Ponownie wyeksportuj ekran z kroku 2 dla użytkownika sudo. Wypróbuj polecenie xclock, aby sprawdzić, czy aplikacje klienckie x działają zgodnie z oczekiwaniami.

# export DISPLAY=localhost:10.0

źródło: https://www.thegeekdiary.com/how-to-set-x11-forwarding-export-remote-display-for-users-who-switch-accounts-using-sudo/

Jeśli widzisz ten błąd w Hudson, spróbuj usunąć katalog .java z katalogu domowego, może to zadziałać.

Michael-O podał przydatne podejście do rozwiązania problemu. Innym sposobem rozwiązania tego problemu jest uruchomienie serwera za pomocą Putty Console.

W moim przypadku zabrakło miejsca w mojej maszynie i napotkałem ten sam problem. Czasami może to być problem z przestrzenią. Sprawdź miejsce w środowisku Linux / Unix i upewnij się, że na komputerze jest wystarczająco dużo miejsca.

sprawdź, czy zmienna $ DISPLAY jest ustawiona, czy nie, za pomocą poniższego polecenia:

echo $ DISPLAY

jeśli zmienna wyświetlania nie jest ustawiona, uruchom poniższe polecenie, aby ustawić (nawet jeśli jest ustawiona, możesz mieć poniżej jedną dla swojej sesji)

eksport WYŚWIETLACZ =: 0,0

w kicie mają również miejsce wyświetlania x jako: 0,0

Miałem ten sam problem na serwerze Linux, na którym pracowałem. Podłączenie javy do wyświetlacza X11 działało w węźle głównym, ale nie na żadnym innym. Po skontaktowaniu się z administratorem okazało się, że obecna wersja naszego systemu planowania zadań (SLURM) nie obsługuje spedycji X11. Musieli zaktualizować SLURM (nowsze wersje SLURM obsługują go), aby działał.

jedyny sposób, w jaki udało mi się to uruchomić, to uruchomienie skryptu z szablonem. np. sudo ./glassfish-3.1.2.2-unix.sh -s template

Spowoduje to zainstalowanie Glassfish w trybie cichym. http://docs.oracle.com/cd/E18930_01/html/821-2427/ghmva.html

Napotykam ten sam błąd, gdy uruchamiam polecenie jconsole na pilocie. Chcę zmodyfikować parametr w jconsole, który działa na zdalnym hoście Linux, mogę zalogować się do hosta za pomocą secureCRT, terminal rzuca te informacje o błędzie. Na szczęście, gdy używasz Putty, jest w porządku. Dziwne....

Jeśli zaczniesz aplikacji na zdalnym serwerze po zalogowaniu się przez ssh wtedy inny sposób byłoby uruchomić ssh z -xparametrem lub dodać ForwardX11 now twojej /etc/ssh/ssh_config. W tym przypadku ssh nie utworzy zmiennej środowiskowej DISPLAY.

Dla mnie problem polegał na tym, że xorg-x11-xauth nie był zainstalowany. Zainstalowałem i zadziałało.

Pakiety, które mam teraz to:

• libX11-common-1.6.3-2.el6.noarch
• libX11-1.6.3-2.el6.i686
• libX11-1.6.3-2.el6.x86_64
• xorg-x11-drv-ati-firware-7.6.1-2.el6.noarch
• xorg-x11-xauth-1.0.9-1.el6.x86_64

Jeśli wyzwalasz swój kod z Jenkinsa, może pomóc włączenie opcji „Uruchom Xvfb przed kompilacją i wyłącz go po”. Pomogło mi.

zmień na innego użytkownika i spróbuj z wyjątkiem roota. mi to pasuje.

Po prostu nie wylogowałem się z roota przed uruchomieniem ./studio.sh Wszystko gotowe.

Dla Ubuntu 17.10 Zainstaluj wirtualny bufor ramki X (xvfb)

apt install xvfb

Dodałem te linie do pliku / etc / profile ...

# Start the X virtual frame buffer (Xvfb)
if [ -f /usr/X11R6/bin/Xvfb ]; then
/usr/X11R6/bin/Xvfb :1 -screen 0 1366x768x32
fi

# Set the DISPLAY variable for the X virtual frame buffer (Xvfb)
export DISPLAY=localhost:1.0

W moim przypadku ten błąd nie był związany z portem DISPLAY. Próbowałem załadować XML do Windchilla (oprogramowanie PLM) i otrzymałem tylko powyższy błąd na terminalu. W pliku dziennika znalazłem raport, że mój plik XML jest uszkodzony . Może ktoś ma podobny problem i może skorzystać z tej odpowiedzi.

Mój problem dotyczył zapory. Wyłączono go tymczasowo.

[EDYCJA] A nazwa hosta serwera wskazywała na inny adres IP. Ustaw go na zwykły serwer lokalny. strace xclockpomogło w debugowaniu tego problemu.

Rozwiązałem ten problem, logując się za pomocą Xorg. Domyślnie użyłem Wayland. Wygląda na to, że Wayland eliminuje większość wad konstrukcyjnych Xorg, ma swoje własne problemy.