Aplikacje X ostrzegają „Nie można połączyć się z magistralą dostępności:” na stderr

30

Wygląda na to, że każda aplikacja z terminala wyświetla ostrzeżenia i komunikaty o błędach, nawet jeśli wydaje się działać poprawnie.

Emacs:

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

Przejawiać:

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

I tak dalej. Czy takie zachowanie jest powszechne, czy coś jest nie tak z moim systemem? Jak rozwiązać te problemy?

— Vosov
źródło

Z mojego doświadczenia wynika, że jest to dość powszechne. Istnieje wiele powiadomień, zarobków i błędów napotykanych przez różne pakiety. Po uruchomieniu z terminala zarobki są wysyłane do terminala, dzięki czemu można je zobaczyć. Gdy uruchamiasz się tak, jak normalnie uruchamiasz aplikację X, nie wyglądasz na ich. Mogą być gdzieś zarejestrowane, ale zwykle nie są, zależnie od aplikacji. Przez lata stosowałem tę prostą zasadę „jeśli aplikacja działa, a błąd nie jest zbyt przerażający, zignoruj go”

— Karl Wilbur,

53

Niestety biblioteki GTK (używane w szczególności przez GNOME) zwykle emitują wiele przerażających wiadomości. Czasami te wiadomości wskazują potencjalne błędy, czasem są całkowicie fałszywe i nie można stwierdzić, która z nich jest bez zagłębiania się w kod. Jako użytkownik końcowy nie możesz nic z tym zrobić. Możesz zgłosić je jako błędy (nawet jeśli program zachowuje się inaczej, wysyłanie fałszywych komunikatów o błędach jest błędem), ale gdy program zasadniczo działa, błędy te są, co zrozumiałe, traktowane jako bardzo niski priorytet.

Ostrzeżenie o dostępności to znany błąd, który można łatwo obejść, jeśli nie używasz żadnej funkcji ułatwień dostępu:

export NO_AT_BRIDGE=1

Z mojego doświadczenia Gtk-CRITICALwynika , że błędy są całkowicie fałszywe; chociaż wskazują gdzieś błąd programowy, nie należy ich zgłaszać użytkownikom końcowym, a jedynie programistom, którzy napisali program (lub bazową bibliotekę - często twórca samego programu nie może nic z tym zrobić, ponieważ jest błąd w bibliotece wywoływanej przez bibliotekę wywoływaną przez bibliotekę używaną w programie).

— Gilles „SO- przestań być zły”
źródło

Tak więc pojawia się ten błąd podczas uruchamiania menedżera okien (niesamowite). Więc gdzie mam to wszystko umieścić export?

— UlfR

@UlfR: Umieściłbyś go w swoim .bashrc.

— Ben Crowell

@UlfR W ~/.profilelub w twojej niesamowitej konfiguracji (nie wiem, jaka jest składnia w niesamowitej). Lub w, ~/.xinitrcjeśli używasz startx, lub ~/.xsessionjeśli używasz klasycznej sesji X11 (w przeciwieństwie do własnego menedżera sesji środowiska pulpitu).

— Gilles „SO- przestań być zły”

@BenCrowell Nie, nie w .bashrc: dotyczyłoby to tylko programu uruchomionego z terminala. Zdefiniowanie zmiennej środowiskowej w .bashrcprawie zawsze jest nieprawidłowe.

— Gilles „SO- przestań być zły”

2

Gdzieś go znalazłem, ale zapomniałem linku do niego.

Aby to naprawić, uruchom:

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

Jeśli nie masz dbus-uuidgen, jest on w pakiecie dbus, który można zainstalować, wydając:

yum install dbus

— PK.Shrestha
źródło

3

Dla mnie to nie rozwiązuje problemu.

— Zeimyth,

1

Nie jestem pewien co do pierwszych błędów, ale wygląda na to, że Firefox naprawił problem g_slice_set_config w wersji 42. Według ich raportu o błędach , wpływa on na glib 2.35 i nowsze.

— MVanOrder
źródło

1

NIE zmieniaj / var / lib / dbus / machine-id! Najpierw sprawdź, czy jest pusty! Przeczytaj stronę podręcznika man!

od: man dbus-uuidgen

Jeśli spróbujesz zmienić istniejący identyfikator komputera w działającym systemie, prawdopodobnie spowoduje to złe rzeczy. Nie próbuj zmieniać tego pliku. Nie rób też tego samego na dwóch różnych systemach; musi być inny za każdym razem, gdy działają dwa różne jądra

mam

połącz z magistralą dostępności: Nie można połączyć się z gniazdem / tmp / dbus-oYuNBK96uX: Odmowa połączenia

komunikat o błędzie, łączenie z innego komputera za pomocą:

ssh -YC nazwa_użytkownika@1.2.3.4

i biegnąc thunar i ewangelię.

Próbowałem tego samego w systemie lokalnym i nie zgłoszono żadnego błędu, który napisałem

cat / var / lib / dbus / machine-id

i ma już jeden identyfikator

Moim zdaniem przyczyną tego błędu jest to, że xserver działający na maszynie używanej jako terminal ma inny identyfikator użytkownika niż system zdalny.

Nie przeprowadzałem więcej eksperymentów, ponieważ zmiana identyfikatora komputera podczas wykonywania kończy się pewnym złym zachowaniem, zgodnie z cytowaną powyżej stroną podręcznika.

— użytkownik350102
źródło