LINUX.ORG.RU

Дак, причина же указана: «could not open display», значит что-то не то в переменных среды DISPLAY и XAUTHORITY. Либо их выставлять в правильные значения, либо как-то под другому пускать из под root'а, допустим через gksu.

mky ★★★★★
()
Ответ на: комментарий от mky

У меня один монитор (ноутбук).
# xhost

No protocol specified
xhost: unable to open display ":0"


пробовал делать export DISPLAY=0:0 - но тоже ничего не дает

вопрос решился так:
sux root dbus-launch <tool>
потом уже под рутом заработало # wifi-radar без dbus-launch и.т.д.
каким образом это пофиксилось, если значение переменной дисплей осталось прежним?
я еще до этого удалил .Xauthority в /root и перезапустил X-ы., однако до sux root dbus-launch <tool> пересоздавшийся .Xauthority не спасал

Marlboro
() автор топика
Ответ на: комментарий от Marlboro

У меня один монитор (ноутбук).

Дак какая разница, если DISPLAY была установлена неправильно, то программы x-клиенты не могут подключится. И по умолчанию ″access control enabled, only authorized clients can connect″, что означает, что в переменной среды XAUTHORITY должен быт указан файл .Xauthority с правильной кукой.

Когда вы запускаете в X-ах терминал, вы получаете эмулятор терминала, который позволяет рабоать обычным текстовым программам, допустим bash, mc и прочим. Но X-овые программы для взаимодействия с X-сервером, не важно какого взаимодействи — настроек (xhost, xset) или выводом графики (firfox, gimp) должны самостоятельно устанавливать с ним соединение ($DISPLAY) и авторизироваться там ($XAUTHORITY).

xhost: unable to open display ":0"

xhost нужно было делать не от root'а, а от пользователя, в том root-терминале у вас были какие-то проблемы с «авторизацией» в X-ах (Invalid MIT-MAGIC-COOKIE-1).

я еще до этого удалил .Xauthority в /root и перезапустил X-ы.

По идее, каждый запуск ″sux″ должен был обновлять этот файл. Возможно, там был «мусор» и всё бы решилось просто удалением .Xauthority и запуском ещё одного ″sux″.

однако до sux root dbus-launch <tool> пересоздавшийся .Xauthority не спасал

Но после перезапуска X-ов, пересоздания /root/.Xauthority и до dbus-launch сообщения об ошибке от wifi-radar стали другими?

А так, если я правильно понял, sux в старой версии (до 1.0.1-6) пропускал переменную среды DBUS_SESSION_BUS_ADDRESS, в результате приложения, запускаемые из под sux пытались подключиться к dbus по не правильному адресу.

То есть по идее, после того как у вас появилась рабочая sux-сессия, в которой нормально запускаяют X-овые приложения, такие как xhost, xclock и т.д. перед запуской wifi-radar нужно было сделать ″unset DBUS_SESSION_BUS_ADDRESS″ и всё.

mky ★★★★★
()
Ответ на: комментарий от mky

Но после перезапуска X-ов, пересоздания /root/.Xauthority и до dbus-launch сообщения об ошибке от wifi-radar стали другими?


Каюсь, не помню, честно.

Большое спасибо и низкий поклон за столь подробное изложение. Это неоценимая помощь :)

Marlboro
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.