Bug 1652456 - User shell environmental variables are not inherited on programs started from desktop/menu
Summary: User shell environmental variables are not inherited on programs started from...
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit
Version: 29
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-11-22 07:19 UTC by Panos Kavalagios
Modified: 2019-11-27 20:18 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-11-27 20:18:40 UTC
Type: Bug

Attachments (Terms of Use)

Description Panos Kavalagios 2018-11-22 07:19:35 UTC
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):
Fedora 29

How reproducible:
Upgrade to Fedora 29.

Steps to Reproduce:
1. dnf system-upgrade download --releasever=29
2. dnf system-upgrade reboot

Actual results:
The new system does not honour the environmental variables set to user's init scripts, like .tcshrc.

Expected results:
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.

Additional info:
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.

Comment 1 Rex Dieter 2018-11-26 13:38:31 UTC
Are you setting these variables for bourne-compatible shells too?  Most likely you need to (since you mentioned .tcshrc)

Comment 2 Panos Kavalagios 2018-11-26 13:46:40 UTC
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.

Comment 3 Rex Dieter 2018-11-26 14:55:15 UTC

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?

Comment 4 Rex Dieter 2018-11-26 14:57:18 UTC
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

Comment 5 Panos Kavalagios 2018-11-27 12:24:53 UTC
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:[218] ~ > setenv FOOBAR testing
panos@bb229:[219] ~ > echo $FOOBAR 
panos@bb229:[220] ~ > bash
[panos@bb229 ~]$ echo $FOOBAR
[panos@bb229 ~]$ export FOOBAR2=testing2
[panos@bb229 ~]$ echo $FOOBAR2
[panos@bb229 ~]$ tcsh
panos@bb229:[201] ~ > echo $FOOBAR2

Comment 6 Rex Dieter 2018-11-27 15:24:16 UTC
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).

Comment 7 Panos Kavalagios 2018-11-27 16:44:40 UTC
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‐
       able. (+)

       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.

Comment 8 Panos Kavalagios 2018-11-27 18:07:41 UTC
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...).

Comment 9 Trevor Cordes 2018-12-01 09:30:48 UTC
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.  :-)

Comment 10 Panos Kavalagios 2018-12-05 13:04:54 UTC
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>.

Comment 11 Rex Dieter 2018-12-05 14:12:45 UTC
We can triage to xorg-x11-xinit which is one level removed from the desktop manager.  (Next step may be triaging to tcsh itself)

Comment 12 Trevor Cordes 2018-12-08 06:28:46 UTC
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  ;-)

Comment 13 Panos Kavalagios 2018-12-10 12:48:05 UTC
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.

Comment 14 Ben Cotton 2019-10-31 20:20:28 UTC
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.

Comment 15 Ben Cotton 2019-11-27 20:18:40 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.