Mengapa upaya penerusan X11 saya gagal dengan "connect /tmp/.X11-unix/X0: Tidak ada file atau direktori"?


33

Di mesin lokal saya, saya menjalankan:

ssh -X me@remotemachine.com

(Untuk kelengkapan, saya juga telah menguji semua hal berikut menggunakan -Y dengan hasil yang identik).

Seperti yang diharapkan, ini mengakses remotemachine.com dengan baik, dan semua tampak baik. Jika saya kemudian mencoba menjalankan xcalc, saya mendapatkan:

 connect /tmp/.X11-unix/X0: No such file or directory
 Error: Can't open display: localhost:10.0

Tapi,

$ ls -la /tmp/.X11-unix/
total 36
drwxrwxrwt 2 root root  4096 2012-11-23 09:29 .
drwxrwxrwt 8 root root 32768 2012-11-29 08:22 ..
srwxrwxrwx 1 root root     0 2012-11-23 09:29 X0

Jadi tidak hanya ada /tmp/.X11-unix/X0, ia memiliki izin universal r / w / x!

Saya sebelumnya menggunakan penerusan x tanpa masalah, meskipun tidak dalam beberapa waktu ...

uname -a di server untuk referensi:

Linux machinename 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux

Telah mencari-cari di web selama beberapa jam sekarang tanpa hasil. Lainnya menyebutkan masalah yang sama, tetapi tidak ada solusi.


Perhatikan bahwa ini adalah file di mesin lokal yang perlu Anda periksa di sini, bukan yang jauh. Saya akan gunakan strace -fo /tmp/trace ssh....untuk memeriksa apakah ia mencoba menghubungkan soket domain Unix itu.
Stéphane Chazelas

Ah! Bisa jadi itu. Anehnya, mesin lokal saya tidak memiliki direktori /tmp/.X11-unix/.
John Doucette

Jawaban:


24

Jika Anda memiliki server X yang berjalan dan DISPLAYvariabel lingkungan diatur ke :0, itu memberitahu aplikasi untuk terhubung ke server X menggunakan soket domain unix yang umumnya dapat ditemukan di Linux di /tmp/.X11-unix/X0(meskipun lihat di bawah tentang namespace abstrak di Linux baru-baru ini) .

Ketika Anda ssh ke mesin remotemachine , sshdpada remotemachine mengatur DISPLAY ke localhost:10(misalnya), yang kali ini berarti bahwa koneksi X dilakukan melalui TCP ke port 6010 dari mesin localhost. sshd on remotemachine mendengarkan koneksi di sana dan meneruskan koneksi yang masuk ke klien ssh. Klien ssh kemudian mencoba untuk terhubung ke /tmp/.X11-unix/X0(pada ujung lokal, bukan remote) untuk menghubungi server X Anda.

Sekarang, mungkin Anda tidak memiliki server X yang berjalan (apakah Anda menggunakan Mac?) Atau mungkin soket domain unix tidak dapat ditemukan di /tmp/.X11-unix yang berarti ssh belum dikonfigurasi dengan benar pada saat kompilasi waktu.

Untuk mengetahui apa jalur yang tepat untuk soket unix, Anda bisa mencoba strace -e connect xlogo(atau yang setara pada sistem Anda) pada mesin lokal Anda untuk melihat apa yang dilakukan aplikasi X normal.

netstat -x | grep X mungkin juga memberikan petunjuk.

Sebagai catatan, pada mesin Wheezy Linux Debian di sini, Xorg mendengarkan pada kedua /tmp/.X11-unix/X0sistem file dan /tmp/.X11-unix/X0pada namespace abstrak (umumnya ditulis @/tmp/.X11-unix/X0). Dari strace, aplikasi X11 tampaknya sekarang menggunakan namespace abstrak secara default, yang menjelaskan mengapa mereka masih berfungsi jika /tmp/.X11-unixdihapus, sementara sshtidak menggunakan namespace abstrak itu.


1
Atau periksa di lsof -p <PID of your local X server>mana Anda harus dapat menemukan /some/thing/Xnfile, nmenjadi DISPLAYnomor Anda .
peterph

Terima kasih, ini cukup membantu. Entah bagaimana file /tmp/.X11-unix/X0 saya dihapus, meskipun masih ada server X yang berjalan. Reboot cepat tampaknya telah menyelesaikan masalah. Mungkin disebabkan oleh beberapa pembaruan yang saya lakukan beberapa waktu lalu.
John Doucette

6
Mengubah variabel DISPLAY dari ": 0.0" menjadi "localhost: 0.0" tampaknya telah melakukan trik untuk saya, setidaknya menghubungkan dari Cygwin ke Linux.
m0j0

FWIW, saya harus menjalankan startxwin(setelah apt-cyg install xinit) dari cygwintuan rumah karena saya menghubungkan Windows lokal ke remote unix
Jonathan

40

Saya memiliki masalah yang sama dengan Cygwin dan Xming, menghubungkan ke server Linux jarak jauh.

Variabel $ DISPLAY saya hanya ": 0,0" di Cygwin, dan meskipun itu bekerja secara lokal, itu tidak bekerja dengan perintah ssh jarak jauh.

Mengubah variabel menjadi "localhost: 0,0" memperbaiki masalah.

export DISPLAY=localhost:0.0

Setelah saya melakukan itu, perintah saya berhasil:

ssh -Yf user@host gvim somefile.c

5
Ini adalah masalah bagi saya bahkan menggunakan Layanan Windows untuk Linux.
Lapo

1
Di server mana Anda menjalankan export ...perintah? 1) mesin lokal 2) server
abalter

1
@abalter Ini berhasil bagi saya menjalankannya di mesin lokal
tralston

3
Saya menghabiskan 2 jam masalah debug dengan Cygwin ssh + VcXsrv karena saya atur DISPLAY=:0 ssh -Y $host. Mengubahnya menjadi DISPLAY=localhost:0masalah yang dipecahkan secara ajaib.
gavenkoa

1
Jawaban bagus, masih membantu menjalankan subsistem ubuntu di windows
Tom Swifty

6

Ini melengkapi jawaban lain dengan informasi spesifik dari Windows-Subsystem untuk Linux. The jawaban yang diterima adalah benar: Anda DISPLAYvariabel tidak dikonfigurasi dengan benar. Namun, tidak terlalu jelas mengapa hanya dari jawaban itu saja, jadi saya memperbaiki dengan jawaban ini.

Jika Anda menjalankan cygwin, atau Windows-Subsystem untuk Linux, dan server X11 Anda berbasis windows (misalnya VcXsrv, atau XMing), kemungkinan server X11 Anda mendengarkan pada port TCP (seperti 127.0.0.1pada port TCP 6000-6010) daripada pada soket domain Unix default ( /tmp/.X11-unix/X0). Soket Unix tidak didukung dengan baik pada Windows saat ini, bahkan di dalam WSL. Berkomunikasi antara program-program di lingkungan seperti Linux dan program yang berjalan langsung pada host windows juga umumnya lebih mudah daripada soket IP.

Ketika Anda menjalankan aplikasi grafis secara lokal (yaitu dari lingkungan Cygwin atau WSL dari host Anda), dan DISPLAYvariabel Anda diatur ke default (yaitu DISPLAY=:0.0), aplikasi pertama-tama akan mencoba untuk terhubung ke server X melalui soket Unix /tmp/.X11-unix/X0. Ini akan gagal, tetapi sebagian besar aplikasi kemudian akan mundur ke koneksi TCP aktif localhost, yang seharusnya berhasil mencapai server, dengan asumsi server X Anda dikonfigurasi dengan default.

Anda dapat mengonfirmasi bahwa ini terjadi dengan mencari connect()panggilan di strace log dari serangkaian aplikasi grafis Anda. Itu umumnya akan terjadi sejak dini, sebelum jendela utama aplikasi muncul.

Perilaku mundur itu tidak terjadi ketika ssh mengarahkan koneksi dari sisi jarak jauh, sehingga Anda mendapatkan kesalahan itu. sshdmemang meneruskan koneksi ke sisi lokal, tetapi koneksi lokal klien ssh menemui jalan buntu karena gagal menjangkau server melalui soket Unix. Anda kemudian mendapatkan ENOENTkesalahan.

Dalam kasus seperti itu, mengubah DISPLAYvariabel Anda untuk menggunakan sintaks TCP bukan :0.0sintaks, dapat memperbaiki masalah:

DISPLAY=127.0.0.1:0 ssh remote some-gui-application

Seperti jawaban lain yang disebutkan, Anda juga dapat mengekspor variabel itu secara interaktif dari prompt shell Anda:

$ export DISPLAY=127.0.0.1:0
...
$ ssh remote some-gui-application

Anda juga dapat menyimpan pengaturan ini secara lebih permanen dengan menambahkan baris itu ke skrip inisialisasi profil shell login Anda (mis ~/.bash_profile.).

Catatan: Beberapa shell memiliki skrip inisialisasi yang berbeda untuk sesi login dan non-login. Misalnya, dengan bash Anda bisa menulis baris itu ke skrip non-login, yaitu ~/.bashrcalih-alih ~/.bash_profile. Jika Anda melakukannya, berhati-hatilah untuk tidak menimpa nilai kustom apa pun yang mungkin telah ditetapkan oleh ssh. Itu akan menjadi kasus jika Anda melompat pertama ke host Anda melalui ssh dan kemudian melompat lagi ke host lain (sehingga bersarang forwarding X11 Anda).


3

Jika host layar Anda adalah macOS , pastikan Anda menjalankan XQuartz .

Pesan kesalahan ini memberi tahu Anda terowongan ssh berfungsi, tetapi tidak tahu cara menyambung ke server X di sisi terowongan Anda .

Di masa lalu yang indah, Mac OS X digunakan untuk memulai XQuartz untuk Anda, tetapi kami tampaknya telah meninggalkan fitur kecil yang menyenangkan ini di terminal versi macOS .


tindak lanjut: Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: localhost:10.0berarti "Anda harus keluar dan SSH kembali setelah memulai XQuartz" FWIW ...
rogerdpack

1

Saya hanya punya masalah yang sama. Yang membingungkan adalah Anda mendapatkan kesalahan tidak-seperti-file pada mesin jarak jauh , tetapi sebenarnya file ini hilang pada mesin (tampilan) lokal .

Hanya untuk melihat apa yang akan terjadi, saya secara manual membuat file yang hilang (fifo, sebenarnya), pada mesin display, seperti ini:

mkfifo /tmp/.X11-unix/X0

Kemudian ssh'ed ke mesin jarak jauh lagi, dan lihatlah, X11 terhubung dengan baik.

Saya tidak tahu apakah ini relevan atau tidak, tetapi mesin display saya bukan Linux, ini Windows dengan cygwin dan VcXsrv. (Mesin remote adalah Linux)


4
/tmp/.X11-unix/X0adalah soket domain unix, bukan FIFO
Samveen

0

Saya mengalami masalah ini menggunakan Subsistem Windows untuk Linux . Masalahnya adalah saya tidak memiliki GUI yang diinstal pada klien, karena asumsi bahwa karena ini adalah mesin Windows, saya memiliki GUI.

Untuk menguji apakah Anda memiliki GUI, jalankan xclockpada klien. Jika Anda mendapatkan kesalahan Error: Can't open display: :0maka Anda harus menginstal program GUI untuk Windows. Saya menggunakan Xserver .

Setelah Anda menginstal GUI, coba perintah berikut:

export DISPLAY=:0
xclock

Jika sebuah jam muncul, maka sukseslah!

Sekarang coba ssh'ing ke server, lalu jalankan xclock. Apakah Anda masih mendapatkan pesan kesalahan terhubung /tmp/.X11-unix/X0: Tidak ada file atau direktori seperti itu Kesalahan: Tidak dapat membuka tampilan: localhost: 10.0 ? Itu karena server sedang mencoba untuk terhubung ke dirinya sendiri untuk menampilkan GUI. Alih-alih, Anda ingin variabel DISPLAY disetel ke alamat yang memungkinkan server mendapatkan komputer Anda. Jadi jika itu di LAN, Anda hanya akan memasukkan nama komputer Anda. Jika Anda terhubung ke server di WAN, maka Anda perlu menentukan IP eksternal router Anda dan memiliki port yang tepat diteruskan.

LAN: export DISPLAY=ComputerName:0
WAN:export DISPLAY=257.257.257.257:0


"Penerusan X" berarti "terowongan protokol X dari aplikasi yang berjalan di mesin jarak jauh (server, dalam kasus Anda) ke mesin lokal (klien, dalam kasus Anda)", jadi tentu saja Anda perlu menjalankan server X (dan tidak "program GUI apa saja") pada mesin lokal. Windows dengan sendirinya tidak memahami protokol X, meskipun "Anda memiliki GUI".
dirkt

-2

Jika itu berfungsi dengan baik dan berhenti bekerja tanpa alasan yang tepat, Mungkin itu bisa menjadi contoh X yang tidak terkendali berjalan di latar belakang. Harap tutup yang menggunakan pengelola tugas.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.