Description of problem:
The environmental variables set to shell init scripts are not inherited in the commands started from KDE menu or desktop. That worked fine in Fedora 28. Starting a command from the tcsh shell prompt works fine.
Version-Release number of selected component (if applicable):
Upgrade to Fedora 29.
Steps to Reproduce:
1. dnf system-upgrade download --releasever=29
2. dnf system-upgrade reboot
The new system does not honour the environmental variables set to user's init scripts, like .tcshrc.
The new system should respect the environment in all commands, whether they have been started from Konsole shell or directly from the start menu or desktop icons.
The http_proxy, https_proxy, no_proxy environmental variables are affected in skype, eclipse and other programs causing interruption of service. The proxy has to be set now manually on allthose programs.
Are you setting these variables for bourne-compatible shells too? Most likely you need to (since you mentioned .tcshrc)
Of course not! Why I need to? I didn't need it that for years. My SHELL environmental variable is set to /bin/tcsh and all the commands started from plasmashell should have respected that. The .tcshrc is run every time the tcsh shell starts.
My question is also why it stopped working after the upgrade from F28 to F29. It's completely inappropriate to the desktop to run with different user shell the startup programs.
What I can tell you is plasmashell doesn't know or care about SHELL, and doesn't explicitly ignore anything in the environment.
What does matter more is your login process. What display manager are you using? sddm? gdm? other?
For example, these items do (should!) get inherited by your environment:
Can you verify that?
for example, /etc/profile.d/kde.csh sets
setenv KDEDIRS /usr
I am using sddm-0.18.0-1.fc29.x86_64. Do you think that is the problem?
I confirm that the /etc/profile.d/*.csh are inherited:
but I wouldn't be sure where it comes from, as the environmental variables set by bash are also inherited in tcsh and vice versa:
panos@bb229: ~ > setenv FOOBAR testing
panos@bb229: ~ > echo $FOOBAR
panos@bb229: ~ > bash
[panos@bb229 ~]$ echo $FOOBAR
[panos@bb229 ~]$ export FOOBAR2=testing2
[panos@bb229 ~]$ echo $FOOBAR2
[panos@bb229 ~]$ tcsh
panos@bb229: ~ > echo $FOOBAR2
The xinit process that sddm uses does appear to use $SHELL, if I'm reading this snippet from /etc/X11/xinit/Xsession correctly:
exec $CK_XINIT_SESSION $SSH_AGENT /bin/sh -c "exec -l $SHELL -c \"$1\""
According to bash's man page:
If the -l option is supplied, the shell places a dash at the beginning of the zeroth argument passed to command. This is what login(1) does.
Not clear to me if this is supposed to launch it as a "login" shell or not (ie, to trigger tcsh to load it's login environment).
From the tcsh manual page:
Startup and shutdown
A login shell begins by executing commands from the system files
/etc/csh.cshrc and /etc/csh.login. It then executes commands from
files in the user's home directory: first ~/.tcshrc (+) or, if
~/.tcshrc is not found, ~/.cshrc, then the contents of ~/.history (or
the value of the histfile shell variable) are loaded into memory, then
~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell
variable) (+). The shell may read /etc/csh.login before instead of
after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or
~/.cshrc and ~/.history, if so compiled; see the version shell vari‐
Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on
thus tcsh *ALWAYS* read the ~/.tcshrc and not only the login shell. Considering that Fedora 28 and Fedora 29 have the same tcsh version "tcsh 6.20.00 (Astron) 2016-11-24" the problem lies probably to KDE, as from the process list I can see:
panos 2147 1855 0 18:16 pts/5 00:00:00 grep --color=auto -i startkde
panos 17282 17276 0 11:38 ? 00:00:00 -/bin/tcsh -c /usr/bin/startkde
panos 17305 17282 0 11:38 ? 00:00:00 /usr/bin/ssh-agent /bin/sh -c exec -l /bin/tcsh -c "/usr/bin/startkde"
panos 17322 17282 0 11:38 ? 00:00:00 /usr/bin/sh /usr/bin/startkde
The startkde has been invoked correctly with /bin/tcsh, first and then /usr/bin/sh. The problem remains, why a command that runs from Konsole inherits the environment, but not any command started from the KDE start menu.
Sorry, the problem is not related to KDE. I have tested GNOME of Fedora 29 in an out-of-the-box VM with GDM login manager and the issue is reproduced there as well. Commands starting from the terminal are inheriting the environment, but not the commands that were added in the applications menu with "alacarte".
I have also updated a Fedora 28 VM and in KDE works fine with GDM login manager. Both commands that are run either from Konsole or KDE start menu are inheriting the environment (added with Edit Applications...).
This just bit me after upgrading to F29 from F28.
Yes, it does not seem to be dependent on what desktop environment you use. I use XFCE/Xorg.
For me the problem is my custom system /etc/csh.login is never executed. I am using lightdm to login. Neither the desktop environment programs (say the command line launcher in XFCE) nor shell windows I open with it have my env vars set in /etc/csh.login. The file is just never being used.
This is an aberration. The process of logging in has used my /etc/csh.login file since the dawn of time, before FC1 in fact (back to RH6 days). Worked fine in F27 and F28.
Something has changed in F29 that seems to make the graphical login ignore both the system csh.login (me) and the user files like .tcshrc (Panos). (I don't use the user files at all.)
Yes, /etc/csh.login isn't really setup as user-configurable, but I've been customizing it forever, and it's valid syntax. I incorporate (and improve upon) the default contents. Moving my csh.login stuff to /etc/profile.d/*.csh isn't really a solution because that stuff is run for every shell started up and csh best practice says you don't put env vars, especially ones that require fancy login-time-only logic to calculate, in those always-run cshrc-type files, you save them for .login/csh.login files.
As Panos said, the tcsh man page is pretty explicit about what files are used and when.
If go to a virtual terminal and login text-mode then everything works as expected. The problem lies with the dm and DE startup. I'm going to see how hard it is to get rid of the dm completely and just go back to shell login and startx... so much easier the old-fashioned way. :-)
I have made some tests with a user having /bin/bash shell in a Fedora 29 out-of-the-box VM. I have added http_proxy, https_proxy, ftp_prox, and no_proxy environmental variables in the ~/.bashrc file. Programs that were started from Terminal, Gnome menu, Alt-F2 were all inheriting the environmental variables. They had *exactly* the same behaviour.
For user having /bin/tcsh shell, only programs that were started from the shell itself, from the Terminal, were able to inherit the proxy variables. When the same program was run from Gnome menu or Alt-F2, no environmental variable was visible. That worked fine in Fedora 28 as already explained. What is the problem of Fedora 29 and non-bash shells? Can we re-assign the ticket to the correct component, as it does not seem to be KDE related. It is a level before starting KDE/Gnome/<your favourite DE here>.
We can triage to xorg-x11-xinit which is one level removed from the desktop manager. (Next step may be triaging to tcsh itself)
Panos, a great way to see what env vars are set for the "graphical stuff" without having to test things manually each time is:
ps auxewww | grep ' xfce4-session ' | grep -v grep | grep -P --color=auto '\bPATH'
Replace "xfce4-session" with something your graphical environment starts very early on. (I put spaces around it to eliminate false positives in other env vars.) And replace PATH with whatever ENV var you like to key on, like your proxy vars.
When I do the above I can see clearly that the desktop environment is not reading or inheriting my csh.login environment vars. Personally, I've figured out how to get startx to work again properly so I've ditched the dm and everything works as expected now :-)
Rex: I suspect the problem is in the GUI init stuff, not tcsh. tcsh between F27/F28 and F29 is all 6.20.00, and nothing really ever changes in tcsh :-) Bash people always forget there are other shells out there ;-)
Thanks for the command. Indeed Fedora 28 reports all my environmental variables just fine and Fedora 29 nothing when the startkde is called:
Fedora 28 startkde process:
/bin/sh /usr/bin/startkde ... PATH=/home/panos/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/ccs/bin:/usr/ucb:/usr/bin/X11:/usr/X11R6/bin:/usr/X/bin:/opt/sfw/bin:/opt/sfw/sbin:/usr/sfw/bin:/usr/sfw/sbin
Fedora 29 startkde process:
/usr/bin/sh /usr/bin/startkde ... PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin
All the legacy path environment set in .tcshrc is not loaded in Fedora 29. I don't think the change of invoking startkde from /bin/sh to /usr/bin/sh has any relation.
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 29 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.