X-приложения предупреждают «Не удалось подключиться к шине специальных возможностей:» на stderr

30

Кажется, что каждое приложение из терминала выдает предупреждения и сообщения об ошибках, даже если оно работает нормально.

Emacs:

** (emacs:5004): WARNING **: Couldn't connect to accessibility bus:    
Failed to connect to socket /tmp/dbus-xxfluS2Izg: Connection refused

Evince:

** (evince:5052): WARNING **: Couldn't connect to accessibility bus:    
Failed to connect to socket /tmp/dbus-xxfluS2Izg: Connection refused

(evince:4985): Gtk-CRITICAL **: gtk_widget_show: assertion 
'GTK_IS_WIDGET (widget)' failed

(evince:4985): Gtk-CRITICAL **: gtk_widget_show: assertion 
'GTK_IS_WIDGET (widget)' failed

Fire Fox:

(process:5059): GLib-CRITICAL **: g_slice_set_config: assertion 
'sys_page_size == 0' failed

Список можно продолжить. Это обычное поведение или что-то не так с моей системой? Как я могу исправить эти проблемы?

— vosov
источник

По моему опыту, да, это довольно часто. Есть много уведомлений, заработков и ошибок, с которыми сталкиваются различные пакеты. При запуске из терминала эти доходы отправляются в терминал, так что вы можете увидеть их. При запуске, как обычно, запускается приложение X, вы им не кажетесь. Они могут быть зарегистрированы где-то, но, как правило, нет, в зависимости от приложения. В течение многих лет я следовал этому простому эмпирическому правилу «если приложение работает и ошибка не слишком страшна, игнорируйте ее»

— Карл Уилбур

53

К сожалению, библиотеки GTK (используемые, в частности, GNOME) имеют тенденцию испускать много страшных сообщений. Иногда эти сообщения указывают на потенциальные ошибки, иногда они полностью ложные, и невозможно сказать, что есть что, не углубляясь в код. Как конечный пользователь, вы ничего не можете с этим поделать. Вы можете сообщать о них как об ошибках (даже если программа в противном случае ведет себя правильно, выдавая ложные сообщения об ошибках - это ошибка), но когда программа в основном работает, эти ошибки по понятным причинам рассматриваются как очень низкий приоритет.

Предупреждение о доступности - это известная ошибка с простым обходным путем, если вы не используете какую-либо функцию доступности:

export NO_AT_BRIDGE=1

По моему опыту, Gtk-CRITICALошибки совершенно ложные; хотя они и указывают на программную ошибку где-то, о них не следует сообщать конечным пользователям, а только разработчику, который написал программу (или основную библиотеку - часто разработчик самой программы ничего не может с этим поделать, потому что ошибка в библиотеке, которая вызывается библиотекой, которая вызывается библиотекой, используемой в программе).

— Жиль "ТАК - прекрати быть злым"
источник

Таким образом, я получаю эту ошибку, когда менеджер окон (удивительный) запускается. Так, где я должен положить что- exportто?

— UlfR

@UlfR: Вы бы положили его в свой .bashrc.

— Бен Кроуэлл

@UlfR В ~/.profileвашей потрясающей конфигурации или в ней (я не знаю, какой синтаксис в этой игре). Или ~/.xinitrcесли вы используете startx, или ~/.xsessionесли вы используете классический сеанс X11 (в отличие от собственного менеджера сеансов в среде рабочего стола).

— Жиль "ТАК - прекрати быть злым"

@BenCrowell Нет, не в .bashrc: это будет применяться только к программе, запущенной из терминала. Определение переменной среды в .bashrcпочти всегда неверно.

— Жиль "ТАК - прекрати быть злым"

2

Я где-то нашел, но забыл ссылку на него.

Чтобы это исправить, запустите:

dbus-uuidgen > /var/lib/dbus/machine-id

Если у вас нет dbus-uuidgen, он находится в пакете dbus, который можно установить, выполнив:

yum install dbus

— PK.Shrestha
источник

3

Не решает проблему для меня.

— Зеймит

1

Я не уверен насчет первых ошибок, но похоже, что Firefox исправил проблему g_slice_set_config в версии 42. Согласно их отчету об ошибках , это касается glib 2.35 и новее.

— MVanOrder
источник

1

НЕ меняйте / var / lib / dbus / machine-id! Сначала посмотрите, если он пуст! Прочитайте справочную страницу!

от: man dbus-uuidgen

Если вы попытаетесь изменить существующий идентификатор машины в работающей системе, это, вероятно, приведет к плохим вещам. Не пытайтесь изменить этот файл. Кроме того, не делайте это одинаковым в двух разных системах; он должен отличаться каждый раз, когда работают два разных ядра

Я получил

подключиться к шине доступности: не удалось подключиться к сокету / tmp / dbus-oYuNBK96uX: соединение отказано

сообщение об ошибке подключения с другого компьютера с помощью:

ssh -YC user_name@1.2.3.4

и работает тунар и вылазит.

Также попробовал то же самое в локальной системе, и об ошибке не сообщалось, я также напечатал

cat / var / lib / dbus / machine-id

и у него уже есть один UUID

Я думаю, что причиной этой ошибки может быть то, что xserver, работающий на машине, используемой в качестве терминала, имеет другой uuid, чем удаленная система.

Я не проводил больше экспериментов, потому что изменение идентификатора машины во время выполнения приводит к некоторому неправильному поведению, согласно приведенной выше странице руководства.

— user350102
источник