Програми X попереджають "Не вдалося підключитися до шини доступності:" на stderr

30

Схоже, що кожна програма з терміналу надсилає попередження та повідомлення про помилки, хоча, здається, працює нормально.

Emacs:

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

Переконайтесь:

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

Firefox:

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

Список продовжується. Чи є така поведінка поширеною чи щось не так у моїй системі? Як виправити ці проблеми?

— восов
джерело

На мій досвід, так, це досить часто. Існує багато повідомлень, заробітків та помилок, з якими стикаються різні пакети. Після запуску з терміналу ці прибутки надсилаються до терміналу, тож ви можете їх побачити. Коли ви запускаєтесь як звичайно, запускаєте додаток 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

— ПК.Шреща
джерело

3

Не вирішує проблему для мене.

— Зейміт

1

Я не впевнений у перших помилках, але, схоже, Firefox виправив проблему g_slice_set_config у версії 42. Відповідно до звіту про помилки , це впливає на glib 2.35 та новіші.

— MVanOrder
джерело

1

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

від: людина dbus-uuidgen

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

Я отримав

підключення до шини доступності: не вдалося підключитися до socket / tmp / dbus-oYuNBK96uX: з'єднання відмовлено

повідомлення про помилку, підключення з іншого комп'ютера за допомогою:

ssh -YC user_name@1.2.3.4

і бігати тунар і випробовувати.

Також спробував те ж саме в локальній системі, і про помилку не повідомлялося, я також набрав

cat / var / lib / dbus / machine-id

і він вже має один ууїд

Я думаю, що може бути причиною цієї помилки, це те, що xserver, що працює в машині, що використовується як термінал, має інший uuid, ніж віддалена система.

Я не робив більше експериментів, тому що зміна ідентифікатора машини під час виконання закінчується деяким неправильним поведінкою, відповідно до цитованої сторінки man.

— user350102
джерело