In my case, customer asked whether the process is still running after automatic logout of the GNOME session.

But when I tested the automatic logout setting of the KCS, it does not work.

And we found this bug in CentOS 7:
~~~
https://bugs.centos.org/view.php?id=9190
~~~

This is probably a bug somewhere in gnome-settings-daemon. The setting seems stored correctly (the message is shown). I'm reassigning this bug to gnome-settings-daemon.

Hi, 

> This is probably a bug somewhere in gnome-settings-daemon. The setting seems stored correctly (the message is shown). I'm reassigning this bug to gnome-settings-daemon.

Thank you Marek.

This seems a bug since RHEL 7.0(I have not tested it in RHEL 6). Fixing this as soon as possible is appreciate.

I have created a patch for g-s-d which should be safe to backport. I did test it locally and it seems to work just fine, see https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/102

The patch has been cherry-picked to gnome-3-32, which should apply cleanly to the RHEL 7.7 g-s-d package (3.28).

Scratch build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=21545076

(In reply to Benjamin Berg from comment #10)
> The patch has been cherry-picked to gnome-3-32, which should apply cleanly
> to the RHEL 7.7 g-s-d package (3.28).
> 
> Scratch build:
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=21545076

Hi Carlos/Benjamin,

Did we add this fix to RHEL7.7? A customer has reported this issue on the RHEL7.7 VM. I have also been able to reproduce the issue on VM.

I think this got lost due to the lack of confirmation that the fix (i.e. scratch build) was working correctly.

I suppose we can just push out an updated package that contains the fix.

This issue seems to still be present in RHEL 7.8. Customer (who's running RHEL 7.6) had indicated to me that their security assessors had pinged them on the lack of idle-logout routines in their builds and "could I look at how they could enable it". Used my Developer subscription to download latest 7.x (a couple hours ago). Followed recommendations in:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/user-sessions#configuring-automatic-logout

Found that the auto logout warning would pop up and the screen would lock soon after, but, that the session was not actually terminated (re-authenticating took back to a desk full of still-open applications and an SSH login showed that the ":0" login-session was active from well before the lock and re-authenticate.

Thomas, a fix for this issue has been identified and is being evaluated for inclusion in a future update of Red Hat Enterprise Linux 7.  In the mean time, you can work around this issue by placing gnome.is_vm=0 on the kernel command line of your guest.

Thank you, Ray. I'm wondering if there's something funky in my test system, though: adding that boot option definitely altered the behavior. However, it looks like it simply killed GUI rather than simply terminating the particular session? As hoped for, I'm no longer ":0" in the return from `who` when SSHed in to monitor the progress. That said, after killing the graphical login user's session, the GUI simply went to black with a flashing line-cursor (at the upper-left of the login screen) ...and no longer responds to input. Was more expecting that it would kill the user-session and return to the initial login screen?

Hi Thomas,

That behavior does sound incorrect.

Can you open a support case at http://access.redhat.com explaining the situation?

Looks like it may be limited to the "physical" framebuffer: if I'm using a test VM (RHEL 7.8) hosted on Hyper-V and connect to its console, then I get the "GUI simply went to black..." behavior. However, if I'm connected via remote Gnome (via Xrdp), then the session terminates once the timeout has been exceeded (and reconnecting via Xrdp gets me a fresh session). 

I need to see what XDMCP-type connection gets me.

Looks like it may be limited to the "physical" framebuffer: if I'm using a test VM (RHEL 7.8) hosted on Hyper-V and connect to its console, then I get the "GUI simply went to black..." behavior. However, if I'm connected via remote Gnome (via Xrdp), then the session terminates once the timeout has been exceeded (and reconnecting via Xrdp gets me a fresh session). 

I need to see what XDMCP-type connection gets me.

The behaviour in this case should depend on whether the system is detecting that it runs inside a VM (i.e. the machine type we are detecting).

There might be a few other factors though, not sure exactly which ones right now.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (gnome-settings-daemon bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:5436

automatic_logout