GNOME Bugzilla – Bug 645736
core components should use DBus names only
Last modified: 2021-06-14 18:20:54 UTC
This is a re-filing of a bug that got lost during the outage. Briefly, here is what I would like to do for gnome-session 3.2: Here on I will use the term "app" for apps, like Firefox, and "component" for things like gnome-keyring, at-spi-registryd, etc. * All core components MUST claim a DBus name * This dbus name MUST be specified in the component's .desktop file (already supported as X-GNOME-DBus-Name) * All core components SHOULD ship with a DBus .service file * gnome-session will by default simply call StartServiceByName on the session bus, and let the service be bus activated; if this fails, it will fall back to running Exec * gnome-session will consider a component running solely based on whether its DBus name is present Rationale: We want this data anyways, and DBus is an excellent way to provide race-free interaction between multiple cooperating processes. * All core components SHOULD *NOT* use XSMP (or the gnome-session DBus XSMP replacement API); if you do, it will be ignored Rationale: The interaction between autostarting .desktop files etc. and XSMP was a horrible mess. See stuff like: https://bugzilla.gnome.org/show_bug.cgi?id=645593#c5
Vincent said something like "but what about ordering where we want nautilus to only appear after the panel has loaded, so you don't see your files shift around?" To which I replied: This is an obsolete example, and moreover, to get a defined user experience on login, the sane way to accomplish that is to have *one thing* responsible for it. In GNOME 3 that's gnome-shell. In fallback mode, well if someone cared they could add an explicit DBus API between panel and nautilus to synchronize. And also, probably most people using GNOME 2 know how we never fixed notification-daemon popping up bubbles immediately after login, before you see anything else...
I also had a comment here that was lost: Activating compoents is racy when there is multiple components providing the same name, in different named sessions, like e.g. notification-daemon and gnome-shell. For that reason we stopped activating notification-daemon and instead autostart it explicitly only in the fallback session. One could probably work around that by having different service directories for each named session, but that again is problematic for setups where the session bus is _outside_ gnome-session
(In reply to comment #2) > I also had a comment here that was lost: > > Activating compoents is racy when there is multiple components providing the > same name Note I actually changed my suggestion above to accomodate distributions: you no longer need a .service file, and gnome-session will, upon getting NoService from the StartServiceByName, simply run the Exec key.
(In reply to comment #3) > (In reply to comment #2) > > I also had a comment here that was lost: > > > > Activating compoents is racy when there is multiple components providing the > > same name > > Note I actually changed my suggestion above to accomodate distributions: you no > longer need a .service file, and gnome-session will, upon getting NoService > from the StartServiceByName, simply run the Exec key. That might work, but kinda invalidates your 'SHOULD ship a service file' above. So it really is 'SHOULD ship a service file if there are no alternative implementations of the service they provide'
Have you considered switching to systemd as session replacement? It has dbus-activation logic implemented.
(In reply to comment #5) > Have you considered switching to systemd as session replacement? It has > dbus-activation logic implemented. What I want to do would help such a switch by avoiding systemd having to deal with XSMP and gnome-session's DBUS-SM protocol for core components. But honestly in a systemd plan, we'd still need to support XSMP for legacy apps, so we'd still need an implementation around, which would still be gnome-session. Maybe gnome-session could morph into gnome-xsmp-server, but...it's more 3.4 material or later IMO. Let's fix the core things first.
To be concrete, we really don't want anything started that can show windows until e.g. gnome-settings-daemon has started and set your theme, and the window manager has started to decorate the windows. So for that example, are you saying that we should add code to the various components to make sure they stall until the WM_S0 and _XSETTINGS_S0 selections appear? What about the apps? We can't add code to every app, so we'd need to make gnome-session not even try to start the apps until WM_S0 and _XSETTINGS_S0 have been snatched up. Or would you try to block this at the gtk_widget_show() level in the same way systemd blocks things at the connect() level? Also, how does all the environment passing contortions that happen at startup fit into this picture?
(In reply to comment #7) > To be concrete, we really don't want anything started that can show windows > until e.g. gnome-settings-daemon has started and set your theme, and the window > manager has started to decorate the windows. > > So for that example, are you saying that we should add code to the various > components to make sure they stall until the WM_S0 and _XSETTINGS_S0 selections > appear? Ah, okay - that is a more valid use of a targeted protocol. But is there anything *besides* gnome-settings-daemon that needs to set X properties? > What about the apps? I'm not talking about getting rid of the Initialization phase. > Also, how does all the environment passing contortions that happen at startup > fit into this picture? Hmm, I'd need to grep for what's running setenv. Ok so, it may make sense for some components to keep using the DBus API. But I think we should at least try to get whatever it is they're doing done over DBus (as I did with a11y in bug 644851 ).
Moving required components to the DBus API is fine with me.
(In reply to comment #8) > Hmm, I'd need to grep for what's running setenv. Gnome Keyring needs to call Setenv on the session manager for at least three environment variables: * Setting SSH_AUTH_SOCK for openssh. * Setting GPG_AGENT_INFO for gnupg. * Setting GNOME_KEYRING_CONTROL for the NSS/Gnutls PKCS#11 integration. In addition, while PAM still exists, gnome-keyring-daemon is generally started by PAM and then initialized when the desktop session starts, based on the user's preferences on what parts they want to enable. Some (slightly out of date) details on gnome-keyring-daemon startup here: http://live.gnome.org/GnomeKeyring/RunningDaemon This is two part initialization is probably still possible under this new gnome-session plan, but it's worth being aware that (sadly) not everything on our desktop today can be solely started by DBus.
(btw, Ryan and I discussed a lot of session management related stuff at GNOME summit last year, and I definitely would like to see systemd take a role in that, and I do believ that this would simplify a lot of things you are looking into)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gnome-session, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-session/-/issues/ Thank you for your understanding and your help.