Couldn't register with accessibility bus...

mathog · 2020-07-29 18:13:55

CentOS 8 (probably irrelevant), this happens:

#Start system with no X11.
#Login as root (no commentary please!!!)
startxfce4 #desktop starts up
#open a terminal, it belongs to "root"
cd ~modules
meld file1 file2 #opens normally, no messages
ssh -Y modules@localhost
#terminal is now running as "modules"
meld file1 file2 #opens but emits following message:
(meld:12047): dbind-WARNING **: 10:57:09.063: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
uxterm & #opens an uxterm belonging to "modules"
meld file1 file2 #opens, but emits preceding message (different PID and time stamp)
export NO_AT_BRIDGE=1
meld file1 file2 #opens, no messages

So it looks like "accessiblity bus", whatever that is, cares about different process owners, yet X11 is just fine putting up whatever window the application wants to run. The NO_AT_BRIDGE setting was found on numerous threads about this issue, none of which could explain what it does or why it works. For instance:

https://bbs.archlinux.org/viewtopic.php?id=176663

Can somebody please explain to me what is actually going on here?

What is the accessibility bus?
Why is the application trying to connect to it?
Why is failing to "register" such a small problem (if it is even technically a problem at all) that the application can then go on and work normally without it?

Thanks.

mathog · 2020-07-31 17:19:27

This appears to be gtk (or gtk+) related. I just ran into another issue with that on CentOS 8 (with XFCE4) and I wonder now how commonly it shows up on other distros using XFCE4? Basically the deal is that if there are two accounts ("A" and "B"), if "A" runs startxfce4, and in a terminal one does "ssh -Y B@localhost", and in that terminal window runs a gtk(+?) application like meld, all hell breaks loose. This is described in gory detail here:

https://forums.centos.org/viewtopic.php?f=54&t=75197

The only other distro I have available for testing is Ubuntu 18.04.4.

On Ubuntu 18.04.4 if "ssh -Y B@localhost" is used when "A" is root it is similar to CentOS. Instead of only some of the xdg processes failing though, all of them do. Probably because of this the repeating error messages do not appear in /var/log/syslog.

However, if on Ubuntu 18.04.4 "su - B" is used instead of "ssh -Y B@localhost" the problem does not appear there, with "A" a regular user and "B" root or vice versa none of the warnings appear either in the terminal or in /var/log/syslog. All 4 of the xdg programs start with meld in either direction (and stay on until the user logs out). One problem was noted though, ~regularuser/.cache/dconf and everything under it was originally owned by "root". That generated a bunch of warnings when "regularuser" tried to open meld because it could not write under that directory. Changing the ownership to "regularuser" resolved that.

Conversely, on CentOS "su - B" failed just as badly as "ssh -Y B@localhost".

I am beginning to suspect that certain developers do not test for this mixed user usage case!

ToZ · 2020-07-31 21:24:39

I'm by no means an expert in accessibility, but I'll try to answer based on what I know.

What is the accessibility bus?

It's a low level protocol that allows accessibility devices (e.g. screen readers) to access the content of toolkit widgets (for more info: https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/). There should be some sort of a11y or AT-SPI deamon running to provide the connection.

Why is the application trying to connect to it?

So that it can get access to and/or manipulate the widget contents.

Why is failing to "register" such a small problem (if it is even technically a problem at all) that the application can then go on and work normally without it?

This sounds like a mis-configuration somewhere. Basically it tires to connect, can't and sends error message, and then moves on. There is probably a problem with accessibility then.

Basically the deal is that if there are two accounts ("A" and "B"), if "A" runs startxfce4, and in a terminal one does "ssh -Y B@localhost", and in that terminal window runs a gtk(+?) application like meld, all hell breaks loose.

This seems like a really odd way of running an application as root. Xfce is a user-based session environment that relies on X and dbus-based session buses. When you try to run that app in that manner, it won't be able to connect to any of those buses. Why not just use gksudo or pkexec? They manage access to existing buses so the apps will work.

I am beginning to suspect that certain developers do not test for this mixed user usage case!

I honestly don't understand the use case. Most DEs are session based and are designed to work in one session. I wonder if such a procedure would work in another DE like gnome or KDE?

mathog · 2020-08-03 18:14:04

ToZ wrote:

I'm by no means an expert in accessibility, but I'll try to answer based on what I know.
What is the accessibility bus?
It's a low level protocol that allows accessibility devices (e.g. screen readers) to access the content of toolkit widgets (for more info: https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/). There should be some sort of a11y or AT-SPI deamon running to provide the connection.
Why is the application trying to connect to it?
So that it can get access to and/or manipulate the widget contents.
Why is failing to "register" such a small problem (if it is even technically a problem at all) that the application can then go on and work normally without it?
This sounds like a mis-configuration somewhere. Basically it tires to connect, can't and sends error message, and then moves on. There is probably a problem with accessibility then.

OK, so it is the tools needed by people with reading, hearing, etc. deficits. My vision isn't fantastic but I'm not there yet and have those sorts of things disabled when I use Windows or a Mac. Perhaps there is a global disable of some sort like that on Linux?

ToZ wrote:

Basically the deal is that if there are two accounts ("A" and "B"), if "A" runs startxfce4, and in a terminal one does "ssh -Y B@localhost", and in that terminal window runs a gtk(+?) application like meld, all hell breaks loose.
This seems like a really odd way of running an application as root. Xfce is a user-based session environment that relies on X and dbus-based session buses. When you try to run that app in that manner, it won't be able to connect to any of those buses. Why not just use gksudo or pkexec? They manage access to existing buses so the apps will work.
I am beginning to suspect that certain developers do not test for this mixed user usage case!
I honestly don't understand the use case. Most DEs are session based and are designed to work in one session. I wonder if such a procedure would work in another DE like gnome or KDE?

I have been using X11 for decades without worrying about any of this stuff, it was always "open a window as any user" and it would just work. With all the complexities of modern desktops, no more apparently. There is no "gksudo" on this box, but pkexec is present. If "A" is root and "B" is "modules" in a terminal this happens:

pkexec --user modules
export DISPLAY=:0.0
cd /tmp
meld one two
#appears in terminal
(meld:2811): dbind-WARNING **: 10:47:21.526: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
#appears in /var/log/messages
Aug  3 10:47:16 poweredge dbus-daemon[772]: [system] Activating service name='org.freedesktop.problems' requested by ':1.46' (uid=3872 pid=2764 comm="abrt-cli status --since=1596476546 " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") (using servicehelper)
Aug  3 10:47:16 poweredge dbus-daemon[2768]: [system] Failed to reset fd limit before activating service: org.freedesktop.DBus.Error.AccessDenied: Failed to restore old fd limit: Operation not permitted
Aug  3 10:47:16 poweredge dbus-daemon[772]: [system] Successfully activated service 'org.freedesktop.problems'
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Activating service name='org.freedesktop.portal.Desktop' requested by ':1.6' (uid=3872 pid=2811 comm="/usr/bin/python3 /usr/bin/meld one two " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Activating service name='org.freedesktop.portal.Documents' requested by ':1.7' (uid=3872 pid=2817 comm="/usr/libexec/xdg-desktop-portal " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Activating service name='org.freedesktop.impl.portal.PermissionStore' requested by ':1.8' (uid=3872 pid=2822 comm="/usr/libexec/xdg-document-portal " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Successfully activated service 'org.freedesktop.impl.portal.PermissionStore'
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Successfully activated service 'org.freedesktop.portal.Documents'
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Activating service name='org.freedesktop.impl.portal.desktop.gtk' requested by ':1.7' (uid=3872 pid=2817 comm="/usr/libexec/xdg-desktop-portal " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:21 poweredge journal[2837]: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Successfully activated service 'org.freedesktop.impl.portal.desktop.gtk'
Aug  3 10:47:21 poweredge org.freedesktop.portal.Desktop[2562]: [E][local-socket.c:60 pw_protocol_native_connect_local_socket()] connect failed: XDG_RUNTIME_DIR not set in the environment
Aug  3 10:47:21 poweredge journal[2817]: Failed connect to PipeWire: Couldn't connect PipeWire remote
Aug  3 10:47:21 poweredge journal[2817]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Successfully activated service 'org.freedesktop.portal.Desktop'
Aug  3 10:47:22 poweredge dbus-daemon[772]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.48' (uid=3872 pid=2811 comm="/usr/bin/python3 /usr/bin/meld one two " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:22 poweredge systemd[1]: Starting Hostname Service...
Aug  3 10:47:22 poweredge dbus-daemon[772]: [system] Successfully activated service 'org.freedesktop.hostname1'
Aug  3 10:47:22 poweredge systemd[1]: Started Hostname Service.
Aug  3 10:48:21 poweredge journal[2817]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
Aug  3 10:49:21 poweredge journal[2817]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
#preceding line repeats at 1 minute intervals (forever)
#these processes started, the command was run in another window:
ps -ef | grep xdg | grep modules
modules     2817       1  0 10:47 ?        00:00:00 /usr/libexec/xdg-desktop-portal
modules     2822       1  0 10:47 ?        00:00:00 /usr/libexec/xdg-document-portal
modules     2826       1  0 10:47 ?        00:00:00 /usr/libexec/xdg-permission-store
modules     2837       1  0 10:47 ?        00:00:00 /usr/libexec/xdg-desktop-portal-gtk

On the plus side, all 4 xdg's started and kept running. On the minus side, that triggered the "Pipewire" message (which had appeared once or twice before, but I never noticed it) and the "Failed to get application states" continues to spam the log file, and that goes on until the "modules" session exits - it does not go away when "meld" exits.

Are all of these processes and messages Gnome related? Maybe there is a way to tell gtk applications that they are not running on Gnome and should not expect any of those desktop functions to work?

ToZ · 2020-08-03 19:17:24

mathog wrote:

ToZ wrote:
I'm by no means an expert in accessibility, but I'll try to answer based on what I know.
What is the accessibility bus?
It's a low level protocol that allows accessibility devices (e.g. screen readers) to access the content of toolkit widgets (for more info: https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/). There should be some sort of a11y or AT-SPI deamon running to provide the connection.
Why is the application trying to connect to it?
So that it can get access to and/or manipulate the widget contents.
Why is failing to "register" such a small problem (if it is even technically a problem at all) that the application can then go on and work normally without it?
This sounds like a mis-configuration somewhere. Basically it tires to connect, can't and sends error message, and then moves on. There is probably a problem with accessibility then.
OK, so it is the tools needed by people with reading, hearing, etc. deficits. My vision isn't fantastic but I'm not there yet and have those sorts of things disabled when I use Windows or a Mac. Perhaps there is a global disable of some sort like that on Linux?

https://unix.stackexchange.com/question … -on-stderr suggest exporting "NO_AT_BRIDGE=1" to quiet the notifications.

ToZ wrote:

Basically the deal is that if there are two accounts ("A" and "B"), if "A" runs startxfce4, and in a terminal one does "ssh -Y B@localhost", and in that terminal window runs a gtk(+?) application like meld, all hell breaks loose.
This seems like a really odd way of running an application as root. Xfce is a user-based session environment that relies on X and dbus-based session buses. When you try to run that app in that manner, it won't be able to connect to any of those buses. Why not just use gksudo or pkexec? They manage access to existing buses so the apps will work.
I am beginning to suspect that certain developers do not test for this mixed user usage case!
I honestly don't understand the use case. Most DEs are session based and are designed to work in one session. I wonder if such a procedure would work in another DE like gnome or KDE?

I have been using X11 for decades without worrying about any of this stuff, it was always "open a window as any user" and it would just work. With all the complexities of modern desktops, no more apparently. There is no "gksudo" on this box, but pkexec is present. If "A" is root and "B" is "modules" in a terminal this happens:

pkexec --user modules
export DISPLAY=:0.0
cd /tmp
meld one two
#appears in terminal
(meld:2811): dbind-WARNING **: 10:47:21.526: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
#appears in /var/log/messages
Aug  3 10:47:16 poweredge dbus-daemon[772]: [system] Activating service name='org.freedesktop.problems' requested by ':1.46' (uid=3872 pid=2764 comm="abrt-cli status --since=1596476546 " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") (using servicehelper)
Aug  3 10:47:16 poweredge dbus-daemon[2768]: [system] Failed to reset fd limit before activating service: org.freedesktop.DBus.Error.AccessDenied: Failed to restore old fd limit: Operation not permitted
Aug  3 10:47:16 poweredge dbus-daemon[772]: [system] Successfully activated service 'org.freedesktop.problems'
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Activating service name='org.freedesktop.portal.Desktop' requested by ':1.6' (uid=3872 pid=2811 comm="/usr/bin/python3 /usr/bin/meld one two " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Activating service name='org.freedesktop.portal.Documents' requested by ':1.7' (uid=3872 pid=2817 comm="/usr/libexec/xdg-desktop-portal " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Activating service name='org.freedesktop.impl.portal.PermissionStore' requested by ':1.8' (uid=3872 pid=2822 comm="/usr/libexec/xdg-document-portal " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Successfully activated service 'org.freedesktop.impl.portal.PermissionStore'
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Successfully activated service 'org.freedesktop.portal.Documents'
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Activating service name='org.freedesktop.impl.portal.desktop.gtk' requested by ':1.7' (uid=3872 pid=2817 comm="/usr/libexec/xdg-desktop-portal " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:21 poweredge journal[2837]: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Successfully activated service 'org.freedesktop.impl.portal.desktop.gtk'
Aug  3 10:47:21 poweredge org.freedesktop.portal.Desktop[2562]: [E][local-socket.c:60 pw_protocol_native_connect_local_socket()] connect failed: XDG_RUNTIME_DIR not set in the environment
Aug  3 10:47:21 poweredge journal[2817]: Failed connect to PipeWire: Couldn't connect PipeWire remote
Aug  3 10:47:21 poweredge journal[2817]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
Aug  3 10:47:21 poweredge dbus-daemon[2562]: [session uid=3872 pid=2560] Successfully activated service 'org.freedesktop.portal.Desktop'
Aug  3 10:47:22 poweredge dbus-daemon[772]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.48' (uid=3872 pid=2811 comm="/usr/bin/python3 /usr/bin/meld one two " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 10:47:22 poweredge systemd[1]: Starting Hostname Service...
Aug  3 10:47:22 poweredge dbus-daemon[772]: [system] Successfully activated service 'org.freedesktop.hostname1'
Aug  3 10:47:22 poweredge systemd[1]: Started Hostname Service.
Aug  3 10:48:21 poweredge journal[2817]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
Aug  3 10:49:21 poweredge journal[2817]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
#preceding line repeats at 1 minute intervals (forever)
#these processes started, the command was run in another window:
ps -ef | grep xdg | grep modules
modules     2817       1  0 10:47 ?        00:00:00 /usr/libexec/xdg-desktop-portal
modules     2822       1  0 10:47 ?        00:00:00 /usr/libexec/xdg-document-portal
modules     2826       1  0 10:47 ?        00:00:00 /usr/libexec/xdg-permission-store
modules     2837       1  0 10:47 ?        00:00:00 /usr/libexec/xdg-desktop-portal-gtk

On the plus side, all 4 xdg's started and kept running. On the minus side, that triggered the "Pipewire" message (which had appeared once or twice before, but I never noticed it) and the "Failed to get application states" continues to spam the log file, and that goes on until the "modules" session exits - it does not go away when "meld" exits.

Are all of these processes and messages Gnome related? Maybe there is a way to tell gtk applications that they are not running on Gnome and should not expect any of those desktop functions to work?

A number of those messages appear to be related to xdg-desktop-portal. See:
- https://bugzilla.redhat.com/show_bug.cgi?id=1793293
- https://bugs.launchpad.net/ubuntu/+sour … ug/1851807
- https://github.com/flatpak/xdg-desktop- … issues/215

mathog · 2020-08-03 21:18:33

ToZ wrote:

A number of those messages appear to be related to xdg-desktop-portal. See:
- https://bugzilla.redhat.com/show_bug.cgi?id=1793293
- https://bugs.launchpad.net/ubuntu/+sour … ug/1851807
- https://github.com/flatpak/xdg-desktop- … issues/215

I had seen the 2nd and 3rd ones before but the first was new to me. That bugzilla report is discouraging since it did not generate any responses in the roughly 6 months since it was filed. I recently filed a separate bug report

https://bugzilla.redhat.com/show_bug.cgi?id=1862581

and today linked the two. I won't be holding my breath for a solution from RH.

The gist of this seems to be that some gtk(+?) library expects to be running in a certain environment and when it isn't it starts up what it can, the other parts are missing, and the result is a barrage of warnings. It is interesting that the xdg processes do not start when "A" owns both the X11 server and the meld process. This is what happens in that case:

#X11 owned by root, as root in a terminal
cd /tmp
meld one two &
#no warnings in terminal
#tail /var/log/messages
Aug  3 14:03:19 poweredge dbus-daemon[772]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.57' (uid=0 pid=5010 comm="/usr/bin/python3 /usr/bin/meld one two " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Aug  3 14:03:19 poweredge systemd[1]: Starting Hostname Service...
Aug  3 14:03:19 poweredge dbus-daemon[772]: [system] Successfully activated service 'org.freedesktop.hostname1'
Aug  3 14:03:19 poweredge systemd[1]: Started Hostname Service.
ps -ef | grep -i hostn | grep -v grep
root        5022       1  1 14:03 ?        00:00:00 /usr/lib/systemd/systemd-hostnamed

The system-hostnamed process exits normally after a brief time. It starts each time meld does. Nothing xdg related appears. I just verified that systemd-hostnamed starts when "B" is not the same as "A". The /var/log/messages indicated that it did, but I had not previously checked with "ps -ef".

That hostnamed is described here:

https://www.freedesktop.org/wiki/Softwa … hostnamed/

which suggests:

#X11 owned by root
#as root in a terminal
gdbus introspect --system --dest org.freedesktop.hostname1 --object-path /org/freedesktop/hostname1 >/tmp/test_root.txt
#as modules in a terminal
gdbus introspect --system --dest org.freedesktop.hostname1 --object-path /org/freedesktop/hostname1 >/tmp/test_modules.txt
diff /tmp/test_root.txt /tmp/test_modules.txt
#no differences

So not very clear why the behavior is different, but probably not due to hostnamed.

Xfce Forum

Sub domains

#1 2020-07-29 18:13:55

Couldn't register with accessibility bus...

#2 2020-07-31 17:19:27

Re: Couldn't register with accessibility bus...

#3 2020-07-31 21:24:39

Re: Couldn't register with accessibility bus...

#4 2020-08-03 18:14:04

Re: Couldn't register with accessibility bus...

#5 2020-08-03 19:17:24

Re: Couldn't register with accessibility bus...

#6 2020-08-03 21:18:33

Re: Couldn't register with accessibility bus...

Board footer