Bug 1547158
Summary: | postsession script not executed on reboot/shutdown | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Joe Wright <jwright> | ||||
Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> | ||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.4 | CC: | 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
Joe Wright
2018-02-20 16:04:43 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. 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 Hello Ray, Do we have any updates on this bug ? 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 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
[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 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? The problem is that the postsession script is not being run.... 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 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. Mike there is a new build -19, can you please check. Thanks -Tom I am comfortable verifying this. Gdm-3.28.2-22.el7 has successfully run my postsession script in every scenario I have tried, repeatedly. 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 |