GNOME Bugzilla – Bug 569039
Selecting desktop environment doesn't work reliably
Last modified: 2011-06-14 00:38:18 UTC
Forwarding https://bugzilla.novell.com/show_bug.cgi?id=460591 ===== I have Gnome and KDE4 installed. With default gdm I can't control which desktop to load. For example: using gnome - log off select kde - gnome loads, log off select gnome - kde loads [...] I notice the SavedSessionNameRead D-Bus signal in gdm-session-worker is emitted many times at the login time. In fact, it should only be emitted at the first time while gdm_session_settings_load is called. After user chooses another DE different from the default one, a calling circle of signals has been built -- gdm-simple-greeter (SelectSession)-> gdm-simple-slave(SetSessionName)-> gdm-session-worker(gdm_session_settings_set_session_name)-> gdm-session-worker(GdmSessionSettings "session-name")-> gdm-session-worker (SavedSessionNameRead)-> gdm-session-slave (SetDefaultSessioName)-> gdm-session-slave("default-session-changed")-> gdm-session-slave(DefaultSessionNameChanged)-> gdm-simple-greeter("default-session-name-changed")-> gdm-simple-greeter(gdm_greeter_panel_set_default_session_name)-> gdm-simple-greeter(on_default_item_changed)-> gdm-simple-greeter("session-activate")-> gdm-simple-greeter(SelectSession).......... and gdm-session-work endlessly set the real session gnome->kde4->gnome->kde4->gnome->kde4 until gdm-simple-greeter exits. You have 50% chance to login to the session you want. ===== Attaching a patch by Ming Xi Wu <mxwu novell com>
Created attachment 127181 [details] [review] Patch
Is this patch still relevant? I can't reproduce the original problem. If there is a cycle here I don't think the proposed patch is the right place to break it, but I guess I won't know for sure until I know: 1) if this is still a problem 2) more details about how the problem is happening
Ming Xi, can you answer questions above?
I can rarely reproduce this bug now. But it is still a potential problem. If you add a log in on_saved_session_name_read, then login to other session through "other" entry, you'll find on_saved_session_name_read has been called many times. For example, this bad behavior can cause the language reset to "C": 1. install 2 DE like gnome and icewm. 2. start gdm and select "other", input user name. now saved language is en_US, and session is GNOME. 3. set session to icewm. 4. cancel. 5. select other and input user name again. 5. select GNOME. 6. inpute password and login. 7. language reset to "C". My patch is OK. After gdm_session_settings_load has been called, saved_*_read loading is done, breaking the cycle here is very safe.
*** Bug 568669 has been marked as a duplicate of this bug. ***
I also bumped into this bug with gdm 3.0.4 and found that there was an dbus message loop formed between the greeter, the slave, and the worker. The loop is caused by dbus_connection_send_with_reply_and_block() in the worker for "SecretInfoQuery". Since the function stops the worker from processing any dbus signal until the slave replies the worker, multiple "SetSessionName" signals are queued. If there are 2 signals with different session name, then a loop will be formed. The loop looks like this: "SelectSession"(greeter) -> "SetSessionName"(slave) -> "SavedSessionNameRead"(worker) -> "SetDefaultSessionName"(slave) -> "SelectSession"(greeter) -> ... For the normal case, i.e. just one "SetSessionName", the loop stops in the slave and the slave will not send the "SetDefaultSessionName" to the greeter. However, if two signal are queued, e.g. gnome and icewm, and processed in a very short interval, the saved session name in the 3 processes will be overwritten over and over again, and this forms the loop. Once the loop is formed, a random session selection will happen.
Created attachment 189147 [details] [review] Stop sending back the saved session name I followed the idea of the patch in comment#1 and made a new patch since the previous patch doesn't work for gdm3. It breaks the loop and works for me.
The problem this sort of patch used to have, is it meant we wouldn't get session updates for ~/.dmrc files that arrived late (because of say nfs home dirs). Now that we use accounts service this sort of patch is probably fine though.
Thanks, I've pushed this.