From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 Description of problem: I added some statements to my ~/.bash_profile to get ssh-add (or equivalent) to prompt me for my password whenever I log in (both text and graphics modes). When I log in using gdm and the default session (so ~/.xsession is run), I am prompted for my password twice. If I log in using kdm or xdm, I am only prompted once. (Reproduced several times, definately not passphrase related!) Adding some lines to ~/.bash_profile confirms that gdm causes ~/.bash_profile to be sourced twice, whereas other display managers (such as kdm and xdm) only source this file once. It seems that gdm is performing an extra login (like "bash --login" or "exec -l"). Please see URL for full details as I submitted to GNOME bug system. Version-Release number of selected component (if applicable): 2.2.3.1-20 How reproducible: Always Steps to Reproduce: 1. touch ~/gdmlogin.log 2. create a new ~/.xsession containing something like: --8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-- #!/bin/sh echo "$(date) starting .xsession" >> $HOME/gdmlogin.log exec gnome-session --8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-- 3. log in to a Red Hat/GNOME system using the "Default" session type (this should invoke /etc/X11/xdm/Xsession, which will fall thru to the default session and call "exec -l $SHELL -c ~/.xsession") 4. read ~/gdmlogin.log, it will have 2 entries 5. repeat with kdm or xdm: only 1 entry will have been added Actual Results: Login script (such as ~/.bash_profile) is sourced twice. Expected Results: Login script (such as ~/.bash_profile) is only sourced once. Additional info:
The steps I gave were bad, the log is in the wrong place. A simple way to reproduce: 1. touch ~/gdmdebug.log 2. create ~/.bash_profile: --8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-- #!/bin/sh echo "$(date): in .bash_profile" >> $USER/gdmdebug.log --8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-- 3. create ~/.xsession: --8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-- #!/bin/sh exec gnome-session --8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-- 4. log in to using gdm with the Default session 5. repeat with xdm or kdm
This could possibly be a duplicate of an old Red Hat 6.1 bug, Bugzilla bug 6965, presuming the user had something that modified $PATH in ~/.bash_profile.
Reproduced this on a clean install of Red Hat Linux 7.3 (which includes essentially the same version of gdm).
See claim in http://bugzilla.gnome.org/show_bug.cgi?id=84827 that this is an xinitrc bug. (Slightly wrong, since we don't run bash --login, we run exec -l gnome-session) I guess I'd rather change gdm, so that the "exec -l" goes right around gnome-session, and we don't run the bulk of Xsession with the profile having been loaded.
I've just replied to that bug saying that the problem disappears if exec is removed from the gdm session scripts. The true cause of the bug should probably be investigated, but it should be safe to remove the exec from the gdm session scripts because something is exec'd in Xsession. In other words, since /etc/X11/xdm/Xsession already calls exec -l $SHELL -c gnome-session or exec -l $SHELL -c startkde or exec -l $SHELL -c $HOME/.xsession it should be fairly safe to remove the initial exec from /etc/X11/xdm/Sessions/Default as it just calls Xsession.
The first bash_profile run occurs when gdm/daemon/slave.c runs -/bin/sh -c 'my-session- command'. The second one occurs in Xsession when it does the exec -l $SHELL ... I am removing the '-' in the slave.c exec line so that everything should work sanely.
Wouldn't it be better to change Xsession instead? Making the change in slave.c means that /etc/X11/xinit/xinitrc.d/* scripts get run without the user's shell environment, which is bad for skkinput (eg XIM=skkinput).
I think doing it in Xsession is right as most of the Xsession script should not run in the user's environment... the "exec -l shell" line marks the start of launching the user's environment. If /etc/X11/xinit/xinitrc.d/ should run in the user's environment, it should probably get run from a hook in /etc/profile.d...
Well, I guess running them from /etc/profile somehow would also be fine. How would you make sure that they are only run when starting an X session though?
In xinitrc-3.29-1, xinput now sources /etc/profile.d/lang.sh which basically fixes the XIM selection configuration problem. So I'm closing this again.