sounds like a misconfiguration issue to me. The a11y bus should really have nothing to do with starting mission-control, or goa-daemon.

well there are two different independent issues:

1) at-spi starts it's on message bus.  this is probably fine and expected.
2) gnome-shell inadvertently activates a telepathy daemon at the login screen.  This is harmless, but unnecessary, so maybe worth fixing.

Does this happen immediately on the login-screen, or only after showing the screen shield? The problem might be that the tp handler is disabled in 'gdm' mode, but not in the 'lock-screen' mode which is shared between 'user' and 'gdm' sessions.

Frederic, can you answer Florians question ?

(In reply to comment #3)
> Does this happen immediately on the login-screen, or only after showing the
> screen shield? The problem might be that the tp handler is disabled in 'gdm'
> mode, but not in the 'lock-screen' mode which is shared between 'user' and
> 'gdm' sessions.

We create a TpAccountManager in the message tray for the message tray menu's status:

https://git.gnome.org/browse/gnome-shell/tree/js/ui/messageTray.js#n1582

This is probably what's launching Telepathy.

(In reply to comment #3)
> Does this happen immediately on the login-screen, or only after showing the
> screen shield? 

Immediatly on the login screen.

(In reply to comment #5)

> We create a TpAccountManager in the message tray for the message tray menu's
> status:
> 
> https://git.gnome.org/browse/gnome-shell/tree/js/ui/messageTray.js#n1582
> 
> This is probably what's launching Telepathy.

Do we even have a message tray on the login screen ?

I believe we might still show a notification or two, but clearly it's just the fact that the message tray is always created leaking out into gdm.

do we want to address this for 3.10 ?

doesn't seem critical for 3.10.0

/me begs to differ, having a process taking 100% cpu is a bit of a problem ;)

what process is taking 100% cpu?

mission-control (I've also reported this issue on https://bugs.freedesktop.org/show_bug.cgi?id=68946 )

would be nice to get rid of the telepathy calls, for 3.10.1

Setting gdm's XDG_DATA_DIRS to a directory containing a stub version of dbus-1/services/org.freedesktop.Telepathy.AccountManager.service and dbus-1/services/org.freedesktop.Telepathy.MissionControl5.service (e.g. with Exec=/bin/false) might be a way to avoid MC without any code changes.

Indeed, I wonder whether gdm's entire XDG_DATA_DIRS search path ought to be something that avoids /usr/local/share and /usr/share?

Another possibility would be for gdm to ship a file resembling /etc/dbus-1/session.conf, but not containing <standard_session_servicedirs />, and run the greeter session under a dbus-daemon configured to read that file (--config /etc/gdm/dbus-session.conf instead of --session, or something). That way, you have full control over service activation, and can avoid having *anything* be service-activatable (symlinking in individual services like AT-SPI if you want them).

http://cgit.freedesktop.org/dbus/dbus/tree/tools/dbus-run-session.c illustrates how to start a dbus-daemon without using dbus-launch. That executable is shipped in D-Bus 1.7, but not in D-Bus 1.6 (although it'd be easy to backport if people want it - I've done that for Debian).

*** Bug 721626 has been marked as a duplicate of this bug. ***

Hmm we could wrap stuff into if (Main.sessionMode.isGreeter) { ... } but that's kind of ugly.

Wouldn't it be better for the login screen to be running in an environment where nothing can be service-activated, except for the few services that you've explicitly "whitelisted"? That's effectively what I suggested in Comment #15, Comment #16.

Analogous: /usr/share/gdm/greeter/applications, /usr/share/gdm/greeter/autostart are already used instead of the standard applications/autostart directories.

(In reply to comment #19)
> Wouldn't it be better for the login screen to be running in an environment
> where nothing can be service-activated, except for the few services that you've
> explicitly "whitelisted"? That's effectively what I suggested in Comment #15,
> Comment #16.
> 
> Analogous: /usr/share/gdm/greeter/applications,
> /usr/share/gdm/greeter/autostart are already used instead of the standard
> applications/autostart directories.

Yeah I think that makes sense. Ray?

note /usr/share/gdm/greeter/applications augments /usr/share/applications, not replaces.

I agree whitelisting dbus services would be a good way to prevent unwanted ones from starting (which is a security win), but it also imposes a hefty maintenance burden, since we'll always be playing catch up.  We do have that situation today with g-s-d plugins, though.

Also, oftentimes the code used at login screen is going to need to be somewhat aware anyway, since it has to gracefully handle the service failing to activate.

I'm not 100% sold on the idea, but not 100% against either.

Augmenting the search path with a higher-priority-than-/usr/share location that stubs the Telepathy services (Comment #15) would also work.

With Telepathy maintainer hat on: I'm not comfortable with the Telepathy services running in the greeter. The greeter environment shouldn't offer arbitrary code execution, and Telepathy is sufficiently complicated that I don't want to try to guarantee that it doesn't do that.

sure, I think we all agree that it shouldn't be running at the greeter.  The question is where do we "cut the trace".  I think at a minimum we should fix it at the source in the shell, but offering some extra line of defense to prevent it from accidentally getting started might makes sense, too. But, the main point I want to make is, we have control over our code and shouldn't rely on it erroring out or something, if we can help it.

https://bugs.freedesktop.org/show_bug.cgi?id=68946 says "moving away the goa plugin fixed the crash and 100% cpu usage: MC is being terminated nicely when user logins."

We really should address the underlying issue here, still: it is not cool that we run mission-control, goa-daemon and a bunch of other stuff on the login screen.

Tentatively closing this as obsolete - the message tray is gone, and with it the menu button that used the telepathy presence to pick its icon.