From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.12) Gecko/20060202 Fedora/1.7.12-1.5.2 Description of problem: Login from the graphic interface (with KDE, GNOME...) do not proceed the /etc/profile file in FC4 (it was working in FC2 and FC3 on these two updated workstations) when using ksh as default shell. tested on: FC2 -> FC4 migration FC3 -> FC4 migration FC4 installed from scratch. Login with "ssh -X" proceed this file but returns an error. The EUID variable in /etc/profile is not set for a simple user. It is for root user. Correcting this error (testing that EUID exists before checking it's value and seting specific root user PATH) correct the /etc/profile execution with ssh. But this file is still not processed with the "graphic connection". My shell is ksh. The problem do not occur if I use bash. Can be related to 149709 (/etc/profile not processed with zsh) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create /etc/profile.d/toto.sh to set an environment variable 2. set your shell to ksh 3. logon using the graphic display (variable is not set in the environment) 4. set your shel to bash 5. logon using the graphic display (variable is set) Additional info:
please try the following: > bash # run another shell as this one will be killed after # exec > exec -l ksh - # now check if the environment variables are set This bug is similar to bug 164112, but for FC4 instead of -devel
Yes, variables are set with "exec -l ksh -". When I connect the linux box with "ssh" they are set too. It seems to be related to the graphical login.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
I'm seeing this exact problem on FC6. Login shell is ksh. Logging in through graphical shell results in profile not being processed. Boot to run level 3 and log in using text login results in the profile being properly sourced. *Clearly* the problem is with the graphical login. Please change the version to FC6. Workaround: Boot to run level 3, use text login, then startx to enter desktop.
Hi Michael, what is the value of echo $SHELL ? does exec -l $SHELL cause /etc/profile to get executed for you?
SHELL is /bin/ksh, and No. ;^) I was already looking into this further, so here's the cut and paste of what I was doing when you updated the bug: From instrumenting Xsession, SHELL is /bin/ksh. Xsession is running: exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH /etc/X11/xinit/Xclients" for me. Some experiments emulating what Xsession is doing: 33> bash [mwc@jackie ~]$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/bin:/usr/games [mwc@jackie ~]$ cat /var/tmp/z #!/bin/sh echo $* echo "PATH is $PATH" [mwc@jackie ~]$ exec -l /bin/sh -c "/var/tmp/z" PATH is /bin:/usr/bin:/sbin:/usr/sbin:/opt/misc/bin:/usr/X11R6/bin:/home/mwc/bin:/home/mwc/bin/i686:. 34> bash [mwc@jackie ~]$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/bin:/usr/games [mwc@jackie ~]$ exec -l /bin/ksh -c "/var/tmp/z" PATH is /usr/local/bin:/usr/bin:/bin:/usr/bin:/usr/games 35> So it appears the ksh is missing the leading '-' being prepended to $0 by bash's exec -l. bash and sh as invoked shells see it just fine and process /etc/profile ok.
okay, thanks. reassigning to ksh.
(In reply to comment #4) > > Workaround: Boot to run level 3, use text login, then startx to enter desktop. As other workaround, I modify /etc/X11/xinit/xinitrc-common. I replace: # Set up i18n environment #if [ -r /etc/profile.d/lang.sh ]; then # . /etc/profile.d/lang.sh #fi with for i in /etc/profile.d/*.sh do if [ -r $i ]; then . $i fi done to process all files in /etc/profile.d at this level. It solves my problem temporarily but $HOME/.profile is still not processed. Patrick
I've found that there is difference between 'exec -l ksh' and 'exec -l /bin/ksh'. I put this into my ~/.profile: export MY_VAR="My variable" And then try to run ksh from bash: [tsmetana@dhcp-lab-165 ksh-20060214]$ exec -l ksh $ echo $MY_VAR My variable $ ps aux | grep ksh tsmetana 31000 0.0 0.0 5200 1600 pts/0 Ss 12:49 0:00 -ksh tsmetana 31037 0.0 0.0 3884 680 pts/0 S+ 12:51 0:00 grep ksh $ Now with full path: [tsmetana@dhcp-lab-165 ksh-20060214]$ exec -l /bin/ksh $ echo $MY_VAR $ ps aux | grep ksh tsmetana 31038 0.0 0.0 5004 1324 pts/0 Ss 12:52 0:00 -/bin/ksh tsmetana 31057 0.0 0.0 3880 676 pts/0 S+ 12:52 0:00 grep ksh $ The fix is quite easy -- ksh strips the path from argv[0] but if the path starts with '-' character, it's removed as well and ksh will never find out that it should run as a login shell. I only wonder whether this was not intentional.
The latest version in rawhide should invoke a login shell whenever argv[0] starts with '-'.