Bug 1370250

Summary:	gnome-session-properties does not save session
Product:	Red Hat Enterprise Linux 7	Reporter:	Giacomo G. Brussino <ggb>
Component:	gnome-session	Assignee:	Ray Strode [halfline] <rstrode>
Status:	CLOSED DUPLICATE	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	afox, cww, desktop-qa-list, mark.crossland, nlandas, pdwyer, rrueck, rstrode, tpelka
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-07-15 17:05:33 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Giacomo G. Brussino 2016-08-25 17:53:33 UTC

Description of problem: gnome-session-properties does not save session


Version-Release number of selected component (if applicable): gnome-session-3.14.0-4.el7.x86_64


How reproducible: easy


Steps to Reproduce:
1. start gnome-session-properties
2. go to options
3. click on remember currently running application
4. log out and log back in


Actual results: the new session does not contain the running applications from the previous session


Expected results: the new session should contain the running applications from the previous session (like for example a terminal.


Additional info: "journalctl -f -UID=<user-uid>" displays:

gnome-session[22747]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x2a00003 (Custom Ses)
gnome-session[22747]: GLib-CRITICAL: g_key_file_load_from_dirs: assertion '!g_path_is_absolute (file)' failed
gnome-session[22747]: gnome-session[22747]: GLib-CRITICAL: g_key_file_load_from_dirs: assertion '!g_path_is_absolute (file)' failed


This should work in gnome 3:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/gnome-session.html

It has not worked in RHEL 7 yet.

Comment 3 Mark Crossland 2019-03-06 08:02:23 UTC

Our users have also reported this issue to us and are keen to get this working.

Comment 4 nlandas 2019-04-29 15:15:23 UTC

Would really like to see this as a built in feature without using third party extensions.

Comment 5 Ray Strode [halfline] 2019-07-15 17:05:33 UTC


*** This bug has been marked as a duplicate of bug 1272442 ***

Comment 6 nlandas 2020-11-06 22:34:06 UTC

So you mark this bug a duplicate of the same/similar bug for the older RHEL 7 and then CLOSED DEFERRED that bug. So is RHEL Gnome going to be able to save sessions?

The main area I see Redhat really lacking is in its GUI and GUI OS management support. It lags behind all other major commercial distributions in this particular area.

Could you at least give us an update as to the status of making Gnome in RHEL support saving sessions?

Comment 7 Ray Strode [halfline] 2020-11-09 15:00:53 UTC

This feature is currently being evaluated for potential inclusion in Red Hat Enterprise Linux 8.  It was considered, previously, for inclusion in Red Hat Enterprise Linux 7, but after some investigation it was determined to be out of scope.  Some of the details of that investigation are documented on bug 1272442 comment 14 .

That comment gets into technical details, so may be hard to follow.  For clarity, I'll paste the summary from it:

```
In summary, getting parity with RHEL 6 is tough because: 

- the save button isn't hooked up (small fix)
- the apps don't register with the session manager so the session manager can't know to restart them on login (bunch of small fixes everywhere)
- the apps don't use XSMP anymore and the session manager doesn't have support for restoring apps that use the non-XSMP api (small fix)
- the window manager doesn't know how to restore the window positions and workspaces of non-XSMP apps.
- the apps don't restore their state on their own when started (bunch of big fixes everywhere)
 
I think this outside the scope of RHEL 7 at this point in the cycle. We have a sister bug for this in RHEL 8 (bug 1701156), so let's defer to that.
```