Java non può connettersi al window server X11 utilizzando "localhost: 10.0" come valore della variabile DISPLAY

Ho uno script che utilizza Java per connettermi a visualizzare X11 nella porta 10.0 su localhost

ma ottengo sempre questo errore

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)

Ho provato di tutto per risolvere questo problema come:

export DISPLAY=:10.0
export DISPLAY=localhost:10.0

Ho provato anche la porta 0.0 ma ricevo sempre lo stesso errore

dopo aver provato xhost

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

come posso risolvere questo problema ho pensato che il server X non fosse in esecuzione, quindi ho provato a startxdire che funziona su quella porta

il mio sistema è Ubuntu server edition 10.04

Questo comando mi ha aiutato a risolvere il problema:

export DISPLAY=:0

È necessario specificare il -Djava.awt.headless=trueparametro all'avvio.

Rimuovere la variabile DISPLAY

unset DISPLAY

Ciò aiuta nella maggior parte dei casi (ad esempio, l'avvio di server di applicazioni o altri strumenti basati su Java) ed evita di modificare tutte quelle righe di comando.

Può anche essere comodo aggiungerlo a .bash_profile per un utente app-server / tools dedicato.

Penso che tu stia lavorando in modalità sudo. Effettua il checkout in modalità utente e riprova

Nel caso in cui qualcuno cerchi di eseguire gli unit test automatizzati tramite il plug-in maven-surefire su CI (jenkins, ..) e ottiene l'errore sopra menzionato, assicurati di aggiornare la configurazione del tuo plug-in infallibile:

<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>

Questo lo risolverà:

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

Per me l'accesso come -Y invece di -X ha funzionato.

Nel caso in cui tu abbia X11 non affidabile come mostrato di seguito, prova invece il flag -Y (se ti fidi dell'host):

Avvertenza : configurazione di inoltro X11 non affidabile non riuscita: dati della chiave xauth non generati

Dopo diversi giorni di inutili sforzi per installare glassfish su raspberry pi 2 con fedora 22 senza testa, di seguito ha funzionato per me senza intoppi

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

ho ricevuto il mio aiuto da qui

Primo: avvia XQuartz

Secondo: ssh -X user @ ip_address

...: inizia il tuo processo

se usi ssh e poi avvii XQuartz otterrai quell'errore

Per prima cosa fallo nella fase di compilazione di Jenkins se usi o imposta / etc / profile:

unset DISPLAY
export DISPLAY=:0

quindi impostare questa proprietà in codice java o utilizzando maven: -Djava.awt.headless = false

Questo ha risolto il mio problema

xhost +

ma tieni presente che xhost +disattiva completamente l'autenticazione e consente a tutti di accedere a tutte le applicazioni sullo schermo.

xhost +si:localuser:root sembra funzionare in modo simile con una corretta autenticazione.

Stavo usando Xming e ho ricevuto un errore simile. Sono stati eseguiti i passaggi seguenti per risolvere il problema:

1. Nel lancio di Xming, seleziona la casella Nessun controllo di accesso.
2. In putty ha eseguito il seguente comando: DISPLAY=XXX.XXX.XXX.XX:0.0; export DISPLAY

Sostituisci XXX.XXX.XXX.XXcon il tuo indirizzo IP.

Risolto. Mi disconnetto e accedo con xorg!

Se stai tentando di esportare il display usando su e ancora non funziona. Questo è ciò che ha funzionato per me. Prova l'inoltro X11 per gli utenti sudo.

Connetti l'host remoto usando l'opzione -X con ssh.

# ssh -X root@remote-host

Ora elenca il set di biscotti per l'utente corrente.

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

Passa a un altro account utente utilizzando sudo. Aggiungi il cookie dall'output del comando sopra all'utente sudo.

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

Esporta nuovamente la visualizzazione dal passaggio 2 per l'utente sudo. Prova il comando xclock per verificare se le applicazioni client x funzionano come previsto.

# export DISPLAY=localhost:10.0

fonte: https://www.thegeekdiary.com/how-to-set-x11-forwarding-export-remote-display-for-users-who-switch-accounts-using-sudo/

Se vedi questo errore in Hudson, prova a rimuovere la directory .java dalla tua home directory, potrebbe funzionare per te.

Michael-O ha fornito un approccio utile per risolvere il problema. Un altro modo per risolvere questo problema è avviare il server con Putty Console.

Nel mio caso non c'era spazio nella mia macchina e ho affrontato lo stesso problema. Alcune volte potrebbe essere il problema dello spazio. Controlla lo spazio nel tuo ambiente Linux / Unix e assicurati che la tua macchina abbia spazio sufficiente.

controlla se la variabile $ DISPLAY è impostata o meno, con il comando seguente:

echo $ DISPLAY

se la variabile di visualizzazione non è impostata, esegui il comando seguente per impostare, (anche se è impostata, puoi averne uno sotto per la tua sessione)

export DISPLAY =: 0.0

nello stucco hanno anche la posizione di visualizzazione x come: 0,0

l'unico modo per farlo funzionare è stato eseguire lo script con un modello. es. sudo ./glassfish-3.1.2.2-unix.sh -s template

Questo installa Glassfish in modalità silenziosa. http://docs.oracle.com/cd/E18930_01/html/821-2427/ghmva.html

Mi imbatto nello stesso errore con te quando eseguo il comando jconsole da remoto. Voglio modificare un parametro su jconsole che viene eseguito su un host Linux remoto, posso accedere all'host usando secureCRT, il terminale lancia queste informazioni sull'errore. Fortunatamente, quando usi il mastice, va bene. Strano....

Se avvii l'applicazione su un server remoto mentre sei connesso da ssh, un altro modo sarebbe avviare ssh con il -xparametro o aggiungere il ForwardX11 notuo file /etc/ssh/ssh_config. In questo caso ssh non creerà la variabile d'ambiente DISPLAY.

Per me, il problema era che xorg-x11-xauth non era installato. L'ho installato e poi ha funzionato.

I pacchetti che ho ora sono:

• 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

Se stai attivando il tuo codice da Jenkins, abilitare l'opzione "Avvia Xvfb prima della compilazione e spegnilo dopo" potrebbe aiutare. Mi ha aiutato.

passare a un altro utente e provare tranne root. per me funziona.

Semplicemente non mi sono disconnesso da root prima di eseguire ./studio.sh All set.

Per Ubuntu 17.10 Installa X virtual frame buffer (xvfb)

apt install xvfb

E ha aggiunto queste righe al file / 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

Nel mio caso questo errore non era correlato alla porta DISPLAY. Stavo cercando di caricare un XML in Windchill (un software PLM) e ho ricevuto solo l'errore sopra riportato sul terminale. In un file di registro ho trovato il rapporto che il mio file XML era danneggiato . Forse qualcuno ha un problema simile e può usare questa risposta.

Il mio problema era con il firewall. Disabilitato temporaneamente.

[EDIT] E il nome host del server puntava a un altro IP. Impostalo semplicemente su localserver. strace xclockha aiutato a eseguire il debug di questo problema.

Ho risolto questo problema accedendo utilizzando Xorg. Per impostazione predefinita, ho usato Wayland. Sembra che Wayland elimini la maggior parte dei difetti di progettazione di Xorg che ha i suoi problemi.

Per me nessuno dei precedenti ha funzionato, ma dopo una lunga ricerca ha funzionato per me.

export DISPLAY=localhost:20.0