Các ứng dụng X cảnh báo không thể kết nối với bus khả năng truy cập: Trực tiếp trên stderr

Có vẻ như mọi ứng dụng từ thiết bị đầu cuối đều đưa ra các cảnh báo và thông báo lỗi, mặc dù nó có vẻ chạy tốt.

Emacs:

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

Chứng minh:

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

Danh sách cứ kéo dài. Là hành vi phổ biến hoặc có một cái gì đó sai với hệ thống của tôi? Làm thế nào để tôi khắc phục những vấn đề này?

Thật không may, các thư viện GTK (được sử dụng cụ thể bởi Gnome) có xu hướng phát ra rất nhiều thông điệp trông đáng sợ. Đôi khi những thông báo này chỉ ra các lỗi tiềm ẩn, đôi khi chúng hoàn toàn giả mạo và không thể biết đó là lỗi nào mà không đi sâu vào mã. Là người dùng cuối, bạn không thể làm bất cứ điều gì về nó. Bạn có thể báo cáo đó là lỗi (ngay cả khi chương trình hoạt động chính xác, phát ra thông báo lỗi giả là lỗi), nhưng khi chương trình hoạt động cơ bản, các lỗi này được coi là mức độ ưu tiên rất thấp.

Cảnh báo khả năng truy cập là một lỗi đã biết với cách khắc phục dễ dàng nếu bạn không sử dụng bất kỳ tính năng trợ năng nào:

export NO_AT_BRIDGE=1

Theo kinh nghiệm của tôi, Gtk-CRITICALlỗi là hoàn toàn giả mạo; mặc dù chúng chỉ ra lỗi lập trình ở đâu đó, nhưng chúng không nên được báo cáo cho người dùng cuối, chỉ cho nhà phát triển đã viết chương trình (hoặc thư viện bên dưới - thường là nhà phát triển chương trình không thể làm gì được vì nó một lỗi trong thư viện được gọi bởi thư viện được gọi bởi thư viện được sử dụng trong chương trình).

Tôi tìm thấy nó ở đâu đó nhưng tôi quên liên kết đến nó.

Để sửa nó, hãy chạy:

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

Nếu bạn không có dbus-uuidgen, thì đó là trong gói dbus, có thể được cài đặt bằng cách phát hành:

yum install dbus

Tôi không chắc chắn về các lỗi đầu tiên, nhưng có vẻ như Firefox đã khắc phục sự cố g_slice_set_config trong phiên bản 42. Theo báo cáo lỗi của họ , nó ảnh hưởng đến glib 2.35 và mới hơn.

KHÔNG thay đổi / var / lib / dbus / machine-id! Đầu tiên hãy xem nó có trống không! Đọc trang người đàn ông!

từ: người đàn ông dbus-uuidgen

Nếu bạn cố gắng thay đổi id máy hiện có trên một hệ thống đang chạy, nó có thể sẽ dẫn đến những điều tồi tệ xảy ra. Đừng cố gắng thay đổi tập tin này. Ngoài ra, đừng làm cho nó giống nhau trên hai hệ thống khác nhau; nó cần phải khác nhau bất cứ lúc nào có hai hạt nhân khác nhau đang chạy

Tôi đã nhận

kết nối với bus khả năng truy cập: Không thể kết nối với socket / tmp / dbus-oYuNBK96uX: Kết nối bị từ chối

thông báo lỗi, kết nối từ máy tính khác với:

ssh -YC user_name@1.2.3.4

và chạy thunar và chứng tỏ.

Cũng đã thử tương tự trong hệ thống cục bộ và không có lỗi nào được báo cáo, tôi cũng đã gõ

cat / var / lib / dbus / machine-id

và nó đã có một uuid

Những gì tôi nghĩ có thể là nguyên nhân của lỗi đó là máy chủ xs đang chạy trong máy được sử dụng làm thiết bị đầu cuối có một uuid khác với hệ thống từ xa.

Tôi đã không thử nghiệm nhiều hơn, bởi vì việc thay đổi id máy trong khi thực hiện kết thúc ở một số hành vi sai trái, theo trang người đàn ông được trích dẫn ở trên.