GNOME Bugzilla – Bug 642367
conflict/confusion between session saving and required components
Last modified: 2011-03-22 15:21:29 UTC
I've had a situation where a session had autosaving turned on, and for some reason the shell had crashed or something, so the session ended with gnome-panel running. Consequently, it ended up being autosaved and from then on overwrote every attempt to add the shell to a session at session start. We need to change the way the session is populated to enforce that required components are being run. Currently, saved apps can provide required components and thus preempt the required components, but we don't really want that to happen ever, as this case shows.
I had a similar problem, i got a mutter (without gnome-shell plugin) in my saved session, so gnome-shell was unable to start. I guess we can filter the session for required components?
Created attachment 180898 [details] [review] untested patch This might be enough (untested)
So, this patch succeeds in preventing the panel from coming up when gnome-shell is a required component, it still gets started in the panel phase. A better solution would be to never save required components in the first place, I think. Or just don't save at all, which is what we've been saying all along. It really doesn't make any sense anymore, now that all session saving ui has been kicked out.
Gross =/ (Not your patch exactly, but the whole problem). What about, quite simply not using XSMP for core components? In other words, have mutter stop speaking XSMP. Which is really the only sane thing; why would you want "session saving" to pick random other processes from the OS core?
I agree 100%. But I'm not a gnome-session maintainer. session saving was forced back in, breaking the clean redesign. Making core components get off xsmp is a good idea in any case.
(In reply to comment #5) > I agree 100%. But I'm not a gnome-session maintainer. > session saving was forced back in, breaking the clean redesign. Come on, that's not true. Session saving was a small benefit on top of fixing XSMP support. It was important to not not blindly log out, without leaving a chance to the user to save his OOo document, or other things. And yes, if we can move apps away of XSMP, things will probably be better.
Session saving makes no sense in the current session design. There is no way to activate it and no way to remove it if you accidentally activate it. We have not designed it at all. It will do unexpected things like this and can't deal with workspace changes well. It has no way of differentiating between apps and core components. I think it is absurd to keep it around.
(In reply to comment #5) > I agree 100%. But I'm not a gnome-session maintainer. > session saving was forced back in, breaking the clean redesign. > Making core components get off xsmp is a good idea in any case. Okay. I'll work on this.
Actually if we want to leave session saving as a hidden "feature", we can't just make mutter/metacity not speak XSMP, because clearly they are involved in the window positioning part. Ugh =/ Maybe Alex is right and gnome-session needs to filter out the list to only include apps. 10000 meter view here, there are 3 totally different systems in use for things for just the OS core (not apps): 1) gnome-session (required_components) 2) autostarted things from /etc/xdg/autostart 3) XSMP For apps: 1) autostarted via ~/.config/autostart 2) Run via gnome-session XSMP 3) Run by the user after login (All of the current gnome-session docs on the wiki don't seem to differentiate between apps and components; not doing so is like a mental virus from the "package" world, you have to fight it!)
(In reply to comment #0) > We need to change the way the session is populated to enforce that required > components are being run. Currently, saved apps can provide required components > and thus preempt the required components, but we don't really want that to > happen ever, as this case shows. Actually, that's exactly how it's supposed to work. The part that's "required" is "windowmanager", not "gnome-shell". As long as you have *some* window manager, gnome-session is happy. If you want to require gnome-shell specifically, then make it a distinct requirement. (Eg, change required_components to just ['desktop-shell'], and have gnome-shell.desktop provide that.) Then metacity+gnome-panel wouldn't be seen as being "equivalent" to it. (Or, if you don't want that replaceability behavior at all, then you should get rid of the whole double-indirection thing ("windowmanager", "panel") and just have the required components list refer to .desktop files directly.) (In reply to comment #4) > What about, quite simply not using XSMP for core components? In other > words, have mutter stop speaking XSMP. Then bug 642666 comes back. The core components need to speak XSMP (or the gnome-session D-Bus protocol) even if session saving goes away completely, in order to coordinate an orderly login. (In reply to comment #0) > I've had a situation where a session had autosaving turned on, and for some > reason the shell had crashed or something, so the session ended with > gnome-panel running. So *that's* the actual bug; the start-panel-and-metacity-on-exit code was only ever supposed to run when you're running gnome-shell from the source tree in a GNOME 2 environment. And that's fixed in git, so now if your gnome-shell-from-packages crashes, it should just crash, and then gnome-session will restart it. So with the next round of packages, it shouldn't be possible to end up in this state any more.
*** Bug 638677 has been marked as a duplicate of this bug. ***
*** Bug 605226 has been marked as a duplicate of this bug. ***
I've pushed changes that fix most of this: - we really always load required components first, as long as they're explicitly required (instead of indirectly, via a generic provides name) - we correctly handle conflicts in provides (we don't launch two components that provide the same thing) - and a few other changes... There's a small corner case still alive which won't affect our default install: if a required component is saved from session A, and session B doesn't have anything that conflict with this required component, then it will still be launched. I'll file a bug for this, but again, minor corner case and it doesn't affect us by default.