After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 126071 - Gdm does not ensure user's programs exit before calling pam_close_session
Gdm does not ensure user's programs exit before calling pam_close_session
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.4.4.x
Other other
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2003-11-03 00:55 UTC by W. Michael Petullo
Modified: 2003-11-06 17:52 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4

Attachments
Patch that causes gdm to run pam_close_session /after/ resetting X server (653 bytes, patch)
2003-11-03 19:54 UTC, W. Michael Petullo 		none Details | Review

Description W. Michael Petullo 2003-11-03 00:55:33 UTC 
Programs such as xscreensaver are still hanging around when gdm executes
pam_close_session.  Gdm 2.4.4.5 does not reset/restart the X server until
after it calls pam_close_session.  As a result, pam_mount often can not
unmount a user's home directory because programs like xscreensaver retain
open file descriptors within $HOME.
Comment 1 W. Michael Petullo 2003-11-03 19:54:18 UTC 
Created attachment 21166 [details] [review]
Patch that causes gdm to run pam_close_session /after/ resetting X server
Comment 2 George Lebl 2003-11-06 17:52:34 UTC 
"Somewhat fixed" in HEAD.  I added a call that just whacks all the
clients with windows using XKillClient (this is being used to for
example clean up the login screen as well).  There is still an
unavoidable race.  The clients themeselves may not die in time.  I
added a sched_yield in there though I doubt that makes much
difference.  Though perhaps if your unmount code tries again in a few
seconds if it doesn't succeed once, things should just work out then.

Alternative fix would be for your module to "fork" a process that
would take care of the unmount asynch and thus could wait untill all
processes have died.