Это дополняет другие ответы информацией, относящейся к Windows -Подсистема для Linux (WSL ). принятый ответ верен :ваша DISPLAY
переменная настроена неправильно. Однако не совсем понятно, почему это так, только из этого ответа, поэтому я исправляю этот ответ.
Если вы используете cygwin или подсистему Windows -для Linux, а ваш сервер X11 основан на Windows -(, например. VcXsrv
или XMing
), более вероятно, что ваш сервер X11 прослушивает TCP-порт (, например порт 127.0.0.1
6000-6010
), а не сокет домена Unix по умолчанию(/tmp/.X11-unix/X0
). В настоящее время сокеты Unix плохо -поддерживаются в Windows, даже внутри WSL. Связь между программами в Linux -, такими как среда, и программами, работающими непосредственно на хосте Windows, также обычно проще через IP-сокеты.
Когда вы запускаете графические приложения локально (, т. е. из среды Cygwin или WSL вашего хоста ), и для вашей переменной DISPLAY
установлено значение по умолчанию (, т. е. DISPLAY=:0.0
), приложения сначала попытаются подключиться к X-серверу через сокет Unix /tmp/.X11-unix/X0
. Это не удастся, но большинство приложений затем откажутся от TCP-соединения на localhost
, которое должно успешно связаться с сервером, если ваш X-сервер настроен по умолчанию.
Вы можете убедиться в том, что это происходит, выполнив поиск connect()
вызовов в журналах strace во время выполнения вашего графического приложения. Обычно это происходит на ранней стадии, до появления главного окна приложения.
Подвох:Это резервное поведение не происходит, когда ssh перенаправляет соединение с удаленной стороны, поэтому вы получаете эту ошибку. sshd
на удаленном компьютере действительно перенаправит соединение X11 на локальную сторону, но локальное соединение клиента ssh не работает -, так как ему не удается связаться с сервером через сокет Unix. Затем вы получаете ошибку ENOENT
.Он не пытается использовать резервное соединение с локальным хостом TCP.
Исправление:В таких случаях изменение переменной DISPLAY
для использования синтаксиса TCP вместо синтаксиса :0.0
может решить проблему:
DISPLAY=127.0.0.1:0 ssh remote some-gui-application
Как и в других ответах, вы также можете экспортировать эту переменную в интерактивном режиме из командной строки:
$ export DISPLAY=127.0.0.1:0
...
$ ssh remote some-gui-application
Вы также можете сохранить этот параметр на постоянной основе, добавив эту строку в сценарий инициализации профиля оболочки входа в систему (, например.~/.bash_profile
).
Примечание.:Некоторые оболочки имеют разные сценарии инициализации для входа в систему и сеансов без -входа в систему. Например, с помощью bash вы можете записать эту строку в сценарий входа, отличный от -, то есть ~/.bashrc
вместо ~/.bash_profile
. Если вы это сделаете, будьте осторожны, чтобы не переопределить какое-либо пользовательское значение, которое могло быть установлено ssh. Это было бы в том случае, если бы вы сначала прыгали на свой хост через ssh, а затем снова прыгали на другой хост (, таким образом вложив свою пересылку X11 ).
При запуске Ubuntu служба автообновления будет выполняться автоматически, поэтому вы получили сообщение об ошибке. Лучше всего позволить автоматическому -обновлению выполнить эту задачу.
Если вам нужно прервать это задание, вы можете:
sudo pkill apt
sudo pkill dpkg
sudo dpkg --configure -a
sudo apt update
Интерфейсная блокировка dpkg
— это /var/lib/dpkg/lock-frontend
; убедитесь, что никакая другая программа не запущена с блокировкой, используя
sudo lsof /var/lib/dpkg/lock-frontend
Если запущенный процесс не обнаружен, удалите файл; в противном случае выйдите из соответствующей программы (или дождитесь ее выхода ). Это должно позволить dpkg
продолжить работу.