Bug 1547158

Summary: postsession script not executed on reboot/shutdown
Product: Red Hat Enterprise Linux 7 Reporter: Joe Wright <jwright>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.4CC: alanm, cpippin, cww, dbasant, jkoten, jraising, mboisver, mclasen, mkolbas, modehnal, rstrode, tpelka
Target Milestone: rc   
Target Release: 7.8   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: gdm-3.28.2-22.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-31 19:38:46 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 1477664, 1727111    
Attachments:
Description Flags
Screenshots from reproducing the bug before component update none

Description Joe Wright 2018-02-20 16:04:43 UTC
Description of problem:
- The /etc/gdm/PostSession/Default script is not executed on shutdown/reboot

Version-Release number of selected component (if applicable):
gdm-3.22.3-12.el7.x86_64

How reproducible:
- 100%

Steps to Reproduce:
1. Edit the /etc/gdm/PostSession/Default script to create a file somewhere on the filesystem
2. Reload GDM
3. Log in as a user and reboot/shutdown the machine (make sure the test file you create does not exist before doing this before reboot/shutdown)
4. Power on the machine and attempt to locate the file

Actual results:
- script does not execute on shutdown/reboot; only on logout

Expected results:
- script runs on shutdown/reboot

Additional info:

Test script:

$ cat /etc/gdm/PostSession/Default 
#!/bin/sh
exec 5> >(logger -t $0)
BASH_XTRACEFD="5"
PS4='$LINENO: '
set -x

touch /imadethis.txt
exit 0


The additional debugging/logging is not necessary because the script never fires, it's just what I used to try to figure out what was going on

Comment 2 Ray Strode [halfline] 2018-02-20 17:03:14 UTC
what's happening is we have this code:

        killpg (pid, SIGHUP);•
•
        worker->priv->child_pid = -1;•
        worker->priv->child_watch_id = 0;•
        run_script (worker, GDMCONFDIR "/PostSession");•

and the killpg() call is leading to the session worker getting a SIGTERM.  The easy fix would be to move the killpg() after running PostSession, but first we should figure out where the SIGTERM is coming from.

Comment 3 Joe Wright 2018-04-16 15:03:54 UTC
From the customer:

retested your workaround, but reboot is still hanging. Running awips2VisualizeUtility in a terminal as my user, it kills alertviz/cave OK.

Inside password-auth I have this:

session     optional      pam_exec	type=close_session	awips2VisualizeUtility

Script does this:

for signal in TERM KILL; do pkill -$signal -u $USER -f alertviz ; pkill -$signal -u $USER -f cave; sleep 5; done

Comment 6 Carroline 2019-08-05 05:01:05 UTC
Hello Ray,

Do we have any updates on this bug ?

Comment 8 Ray Strode [halfline] 2019-08-05 13:30:28 UTC
Nope, this bug is currently tentatively targetting 7.8, but not candidate builds have yet been made.  Moving to POST, though, since fix is pointed out in comment 2

Comment 12 Pavlin Georgiev 2019-09-02 11:44:30 UTC
Created attachment 1610751 [details]
Screenshots from reproducing the bug before component update

TEST SETUP 1
Distro: RHEL 7.4
Component version: gdm-3.22.3-11.el7


TEST PROCEDURE 1
1. Download and install Brew build gdm-3.22.3-12.el7.
2. Prepare the script according to instructions.
3. Reproduce the bug.
The bug appears.

[root@qe-dell-ovs5-vm-41 gdm]# ll
total 12
drwxrwxr-x 2 test test  280 Sep  2 10:22 common_procedures
drwxrwxr-x 2 test test  127 Sep  2 10:22 configurations
drwxrwxr-x 2 test test 4096 Sep  2 10:22 data
drwxrwxr-x 3 test test   61 Sep  2 10:22 features
-rw-rw-r-- 1 test test  885 Sep  2 10:22 mapper.yaml
-rwxrwxr-x 1 test test 2105 Sep  2 10:22 runtest.sh

Comment 13 Pavlin Georgiev 2019-09-02 11:46:59 UTC
[root@qe-dell-ovs5-vm-41 /]# ll                                               
total 28                                                                      
lrwxrwxrwx.   1 root root    7 Sep  2 05:31 bin -> usr/bin                    
dr-xr-xr-x.   4 root root 4096 Sep  2 09:39 boot                              
drwxr-xr-x   19 root root 3080 Sep  2 10:33 dev                               
drwxr-xr-x. 148 root root 8192 Sep  2 10:33 etc                               
drwxr-xr-x.   3 root root   18 Sep  2 05:36 home                              
lrwxrwxrwx.   1 root root    7 Sep  2 05:31 lib -> usr/lib                    
lrwxrwxrwx.   1 root root    9 Sep  2 05:31 lib64 -> usr/lib64
drwxr-xr-x.   2 root root    6 Mar 10  2016 media
drwxr-xr-x.   5 root root   55 Sep  2 09:48 mnt
drwxr-xr-x.   3 root root   16 Sep  2 09:52 opt
dr-xr-xr-x  130 root root    0 Sep  2 06:32 proc
dr-xr-x---.   7 root root 4096 Sep  2 10:27 root
drwxr-xr-x   40 root root 1220 Sep  2 10:43 run
lrwxrwxrwx.   1 root root    8 Sep  2 05:31 sbin -> usr/sbin
drwxr-xr-x.   2 root root    6 Mar 10  2016 srv
dr-xr-xr-x   13 root root    0 Sep  2 06:32 sys
drwxrwxrwt.  12 root root 4096 Sep  2 10:36 tmp
drwxr-xr-x.  13 root root  155 Sep  2 05:31 usr
drwxr-xr-x.  21 root root 4096 Sep  2 09:52 var

Comment 14 Pavlin Georgiev 2019-09-04 12:41:30 UTC
I try to reproduce and verify bug https://bugzilla.redhat.com/show_bug.cgi?id=1547158.

I used the following setup and procedure:
TEST SETUP 2
Distro: RHEL 7.7
Component version: gdm-3.28.2-16.el7


TEST PROCEDURE 2
1. Download and install Brew build gdm-3.28.2-17.el7.
2. Prepare the script according to instructions.
3. Reproduce the bug.

  $ cat /etc/gdm/PostSession/Default
  #!/bin/sh
  exec 5> >(logger -t $0)
  BASH_XTRACEFD="5"
  PS4='$LINENO: '
  set -x

  touch /imadethis.txt
  exit 0


I expect to see file after restart:
/imadethis.txt

But it is missing in /.

What is the reason? Do I test correctly?

Comment 15 Joe Wright 2019-10-03 20:56:49 UTC
The problem is that the postsession script is not being run....

Comment 16 Michael Boisvert 2019-10-09 18:16:59 UTC
Using my own testing, I do not see the PostSession script being run during a reboot/shutdown scenario. It works when you log out/in. Gonna punt this back to devel's, correct me if I am wrong. 

This is the very simple test we have run to check this in the past:

1. Put this content in the file /etc/gdm/PostLogin/Default:
     #!/bin/sh
     echo "running PostLogin" >> /tmp/testlog

2. Make the file /etc/gdm/PostLogin/Default executable.

3. Put this content in the file /etc/gdm/PreSession/Default:
     #!/bin/sh
     PATH="/usr/bin:$PATH"
     echo "running PreSession" >> /tmp/testlog

4. Put this content in the file /etc/gdm/PostSession/Default:
     #!/bin/sh
     echo "running PostSession" >> /tmp/testlog
     exit 0

5. Restart machine.

End result after reboot should show the following in /tmp/testlog:

running PostLogin
running PreSession
running PostSession

Comment 17 Ray Strode [halfline] 2019-10-16 18:39:24 UTC
Looking in my PostSession script on my test VM, i see i'm touching a file to /tmp.

Given /tmp isn't preserved across reboots, it's pretty clear that I only tested logout and not reboot when I wrote the patchset.

I think what's happening is we're hitting another bug that prevents the session worker from getting killed properly when the main gdm daemon dies.

This has been fixed upstream (https://gitlab.gnome.org/GNOME/gdm/commit/039e3422f4764dbdf105244a174da061d4e38344 and related commits)

I'll try cherry-picking those commits and retest reboot/shutdown specifically.

Comment 18 Tomas Pelka 2019-10-22 09:49:03 UTC
Mike there is a new build -19, can you please check.

Thanks
-Tom

Comment 32 Michael Boisvert 2019-10-30 16:45:51 UTC
I am comfortable verifying this. Gdm-3.28.2-22.el7 has successfully run my postsession script in every scenario I have tried, repeatedly.

Comment 34 errata-xmlrpc 2020-03-31 19:38:46 UTC
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, 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/RHSA-2020:1021