lightdm lefts a11y (at-spi*) process behind

(more info on the linked downstream bug)

These processes will have been started by the greeter, I'm assuming lightdm-gtk-greeter in this case. The greeter needs to clean up its child processes on exit.

I noticed that too a while ago, sometimes it also leaves an DBus daemon around. lightdm-gtk-greeter does not start them explicitly, a ATK GTK module does that when installed. Robert, what exactly should the greeter do, is there some code example in the unity greeter handling this?

We use a hack in Ubuntu to stop the D-Bus daemon when the greeter quits [1] which probably cleans up most hangers-on. Logind is supposed to do a better job of this, but I'm not sure if we should be calling Terminate() in logind to force the session to clean up (GDM doesn't appear to do this).

[1] http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/view/head:/debian/lightdm-greeter-session

Yeah sorry, since the processes where children of lightdm I reported the bug here, but this is indeed using lightdm-gtk-greeter so maybe we can reassign.

Also, in my case this is with systemd as init and logind running.

The lightdm-greeter-session doesn't seem to help in this case, at-spi uses its own private DBus server which is launched by at-spi-bus-launcher which in turn seems to be run by the at-spi GTK module.

Should this be reassigned to lightdm-gtk-greeter then? What's the correct fix?

Any news on this?

I'm afraid that we have not had a chance to clear this one up yet. In the meantime, I suggest using the patch provided below as a stopgap while we figure out a solution.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760740#23

Can you test attached patch for 1.8.5 version? This solution is "nicer" than one used 1.8.5-2 debian package.
1. NO_AT_BRIDGE=1 prevents starting at-spi by Gtk
2. If lightdm-gtk-greeter.conf contains "keyboard=something" then greeter starts at-spi-bus-launcher and _kills_ it on exit.

To be honest, I know almost nothing about at-spi work so there are can be some hidden problems.

Thanks for the patch, which indeed looks a bit nicer. I'll try the patch, but I'm unsure though if the release team (who accepted the workaround in Debian Jessie) will allow this other solution.

I have tested it, at-spi still automatically gets started.

(with nothing in keyboard, I mean, and it lives on during the user session).

Strange, I tested it with Testing (VirtualBox) and ArchLinux (the same problem, real hardware) - patch works fine. I mean, there is no lightdm at-spi processes after login.

> If lightdm-gtk-greeter.conf contains "keyboard=something" then greeter starts at-spi-bus-launcher and _kills_ it on exit.
This message is misleading, my fault - I posted wrong patch. In this version greeter always launch at-spi. Anyway, greeter must kill it on exit.

Silly question - did you reboot your PC?

Mmm, I hadn't rebooted, no, I had just restarted lightdm. Now that I have, things are indeed going fine. It's odd, I thought it would have been enough. Anyway, it seems to be working fine indeed, thanks!

Mmm, as the result of this, accessibility does not any more at all in lightdm. This is because setting NO_AT_BRIDGE to 1 would just completely disable accessibility, not only disabling autostart of at-spi-bus-launcher. This is thus not a proper solution. To summarize what we want:

- we need to kill the at-spi bus before starting the user session
- we don't want gtk-3 to auto-start at-spi-bus-launcher, since we wouldn't know how to kill it.
- we want accessibility to work in the gtk greeter.

So I propose the attached patch:

- if the at-spi command is not known, i.e. we assume that we don't know about accessibility, we don't know how to start it, so won't know how to kill it, so we set NO_AT_BRIDGE to 1 to make sure that gtk-3 won't unexpectedly load it either.
- if the at-spi command is known, we start the at-spi bus early, before any gtk initialization (which would auto-start the at-spi bus)

What do you think?

Currently working on mate related accessibility stuff for 16.04. I haven't yet tested Samuel's patch, from looking at the code and how it handles the closing of pids, it looks sound. Will test, and if it works out, I am going to apply it to the lightdm-gtk-greeter package in 16.04.

Hello,

Luke, how well you did your tests go? We need some fix in Debian, otherwise the box will be completely inaccessible at reboot after system installation...

One thing worth noting here is that as long as the AT_SPI_COMMAND is present (because the package is installed, for example), the program will be started. While it might be desirable to have it enabled by default (otherwise it kind-of defeats its purpose), it might also be worth considering a way to disable it.

What would be the preferred way for doing this? A new item in /etc/lightdm/lightdm-gtk-greeter.conf?

There is a possibility that this issue should be resolved without additional patches with the below commit. Can you test this and confirm?

http://bazaar.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/trunk/revision/367

Hello,

Well, no, I don't see how it could fix it, see my patch and my comment https://bugs.launchpad.net/lightdm/+bug/1366534/comments/16 : “we [have to] start the at-spi bus early, before any gtk initialization (which would auto-start the at-spi bus)”.

Without my patch, gtk initialization auto-starts the at-spi bus, and thus lightdm can't know how to terminate it since it didn't start it itself.

I have attached an update of my proposed fix.

Hello,

We are now having another round of discussions on this here: https://mail.gnome.org/archives/orca-list/2017-November/msg00016.html
I would also suggest to apply Samuel's patch proposed in the comment #22.
I assume GTK does not load its ATK module by it-self Thus spawning at-spi2-bus-launcher. It only does this when configured (e.g. by setting up GTK_MODULES environment variable) or patched to do so. It's why I have completelly missed this when dealing with LP: #1483864 last year. As I understand it GTK_MODULES is only needed for GTK+2 but it's now being used almost everywhere when we would like to ensure accessibility support is available whenewer possible. For example on arch linux with systemd lightdm 1.24.0 and lightdm-gtk-greeter 2.0.3 all is working the way it should. On debian and Slint it's failing.
So once again if possible we would like to have Samuel's patch looked at one more time and applied as soon as possible so it will gracefully handle such a setup.

Oh yeah and systemd makes another round of differences.
The LP#1670933 addresses the same thing in a different way however that may not work with configurations where at-spi2-bus-launcher is not activated via systemd.