bash not picking up /etc/environment

[stringhaml]

When setting up http_proxy="http://my.proxyserver.example.com" and other such environment variables in /etc/environment they are not exported when opening a new bash session.

for example:
user@mycomputer:~$ cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
ftp_proxy="http://my.proxyserver.example.com:1234"
http_proxy="http://my.proxyserver.example.com:1234"
https_proxy="http://my.proxyserver.example.com:1234"
no_proxy=example.com,*.example.com,10.0.0.0/8,192.168.0.0/16,127.0.0.0/8,localhost"
socks_proxy="http://my.proxyserver.example.com:1235"

exit bash, re-open, and do a printenv they are not listed.

[aseering]

Thanks @stringhaml for posting! I believe this is conceptually the same issue as #816 ; it probably shares the same workaround.

WSL team, any further thoughts on that issue? I feel like I recall a bunch of discussion about it somewhere on one of these tickets prior to the Anniversary release, but I haven't heard much since.

[stringhaml]

Thanks for your response @aseering! I tried adding the --login option as described in #816 but it didn't resolve the issue. I should also mention I'm running on the following version of windows:

OS Name: Microsoft Windows 10 Enterprise
OS Version: 10.0.14393 N/A Build 14393

[jackchammons]

@stringhaml Upgrading to a newer release of Windows via the insider program and using the workaround from #816 should fix this issue. Let us know if that works for you.

[johnnyodonnell]

How can you upgrade to a newer release?

[benhillis]

@johnnyodonnell - supposedly you can download Creator's Update today via the media creation tool, but it "officially" releases on 4/11.

[rlabrecque]

This is still a problem with 1703 unfortunately.

Running bash --login doesn't help.

Right now there seems to be no way to set an environment variable that is used in all contexts?

I tested this with WSL and Ubuntu Server 16.04. I was expecting WSL to behave just like Ubuntu in this case.

I added RL_ENVIRONMENT=1 to my /etc/environment file and RL_BASHRC=1 to ~/.bashrc
testing.sh:

#!/bin/bash
echo RL_ENVIRONMENT: $RL_ENVIRONMENT
echo RL_BASHRC: $RL_BASHRC

WSL 16170 (1703/Creators Update):

$ echo $RL_ENVIRONMENT

$ echo $RL_BASHRC
1
$ sudo echo $RL_ENVIRONMENT

$ sudo echo $RL_BASHRC
1
$ ./testing.sh
RL_ENVIRONMENT:
RL_BASHRC:
$ sudo ./testing.sh
RL_ENVIRONMENT: 1
RL_BASHRC:

Ubuntu 16.04:

$ echo $RL_ENVIRONMENT
1
$ echo $RL_BASHRC
1
$ sudo echo $RL_ENVIRONMENT
1
$ sudo echo $RL_BASHRC
1
$ ./testing.sh
RL_ENVIRONMENT: 1
RL_BASHRC:
$ sudo ./testing.sh
RL_ENVIRONMENT: 1
RL_BASHRC:

Using sudo su - does pick up /etc/environment and functions the same in both WSL and Ubuntu
Using sudo su -; su defaultuser does cause WSL to work as expected in this scenario.

I also use HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss AppendNtPath 0, since I was hoping that would help. I could see this happening to not have /etc/environment stomp on

Somewhat related: #816

[thesmart]

It's been over a year and there still isn't a way to properly load the environment in Ubuntu? This is basic stuff. Are there any updates on how to source /etc/environment as it would in any standard Ubuntu install?

[vient]

Still not working on 1709 (16299.248).

[therealkenc]

This got marked as a dupe of #816 a long time ago, but that issue was hence marked fixinsiderbuilds. I think it was marked as such because quoth:

As of build 16188 when running bash.exe without arguments (or with the ~ argument) bash will be launched as a login shell.

/etc/environment would be a different kettle of fish. This issue was conveniently never closed so I'll just de-dupe. Ref #352 which is along the same PAM lines.

[wpwoodjr]

Is there any progress on getting WSL to pick up /etc/environment under Ubuntu? If not what is the best work around?

[falfiya]

Still present in 1809. One workaround right now is to use /etc/profile or /etc/profile.d/. Those seem to actually be used, unlike /etc/environment.

[oldium]

I just tried it on build 18975 and WSL 2 (Ubuntu 18.04 LTS image) - /etc/environment is used by a call to bash -c "set | grep PATH".

[clearnote01]

After sudo login I am able to use variables set in /etc/environment. Interestingly WSL with Ubuntu doesn't seem to read variables set in ~/.pam_environment

[oldium]

Tested in build 19041.21, not working. Tried to run bash -c "set" and checked the PATH and one more variable, which is in /etc/environment, but not seen in the output. This is broken.

[huangjj27]

Perfect work around for me: using WSLENV

[cawoodm]

WSL 10.0, Ubuntu 16.04 - /etc/environment completely ignored.
Add your vars to ~/.bashrc and then you have them in bash but not in pwsh.

[Aphanasiy]

Try to rewrite /etc/enviroment using sudo. Weird, but for me is true that cat /etc/enviroment and sudo cat /etc/enviroment do different things

[Andrei-Paul]

Windows 10 Linux Subsystem
███████████████████
BUILD: 19041
BRANCH: vb_release
RELEASE: Ubuntu 20.04.1 LTS
KERNEL: Linux 4.19.104-microsoft-standard

/etc/environment still not picked up by fresh run in Win10 2004 by wsl2 + Ubuntu.

[falloutphil]

Confirm this is an issue in Win10 2004 + Ubuntu 18.04. It's quite problematic for environment setup for non-interactive shells - for example PyCharm's WSL integration users the launcher exe which won't pick-up /etc/profile.d scripts - and /etc/bash.bashrc (above the interactive check) doesn't work. It seems there is no way of having an env var set without interactively logging in.

[smaktacular]

Confirmed also on Win10 2004 + Ubuntu 20.04, WSL2

Is there a way to pass the --login option to a WSL instance started from Windows Terminal?

edit: nevermind, while read line; do export $line; done < /etc/environment inside ~/.zshrc or ~/.bashrc is sufficient.

[janekb04]

Confirmed on Win10 20H2, Ubuntu 20.04, WSL2. Still not working.

[dineiar]

Still an issue using Windows 11 Home 21H2 build 22000.132 and Ubuntu 20.04 running on WSL

[8ar10der]

I am not sure. I think this issue related to the systemd.
To get a full functional systemd on WSL2, I always use genie. (https://github.com/arkane-systems/genie)

If I boot the WSL via genie, the pam_env can be loaded.

(PS: because the genie create a login shell so the issue may not related to the systemd. A login shell is the important point)

[solvingj]

@jackchammons @therealkenc It's been 6 years since this was opened, 4+ years since de-duped from #816 . 3 years since linked to #4232, and since then no maintainers from MS have commented or provided update on these two critical bugs. Are these things on any internal roadmap or associated with any project plan to be done in the next year? Or better yet, could you comment as to whether or not anyone is actively working on them?

[trallnag]

Let's hope Poettering cleans up this mess now that he's with Microsoft 😜

@8ar10der, I don't think it has anything to do with login shells. bash --login or zsh --login does not make a difference at least for me.

[trallnag]

Related: linux-pam/linux-pam#481

---

Interesting finding: /etc/environment is parsed once sudo login is performed. Why does the default login not work?

---

Does anybody know what tool WSL uses to perform the login? Maybe what is missing is a dedicated config in pam.d for that.

---

I found a way to get into the WSL distribution from PowerShell that uses /bin/login and by that parses /etc/environment.

wsl.exe -u root -- /bin/login -f <username>

Found this by googling here: https://uzxmx.github.io/wsl-tricks.html

[lombervid]

Any update on this? I still have this problem using Windows 11 build 22621.1702.

I found a way to get into the WSL distribution from PowerShell that uses /bin/login and by that parses /etc/environment.

wsl.exe -u root -- /bin/login -f <username>

Found this by googling here: https://uzxmx.github.io/wsl-tricks.html

This works for me, but then every time I open VS Code within WSL, it opens from Windows' file system instead of WSL's

I ended up using WSLENV to set my environment variables. I added something like this to my Powershell $PROFILE:

$env:MYENV = "some-value"
$env:WSLENV = "${env:WSLENV}::MYENV"

And then setting my windows terminal profile:

{
  "name": "Ubuntu",  
- "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc",
+ "commandline": "pwsh.exe --command \"wsl --cd ~\"",
},

Or executing directly from powershell:

ubuntu

This works, but I don't feel like this should be the way to do it.

[npuichigo]

any update?

[iamexe]

@jackchammons @therealkenc It's been 6 years since this was opened, 4+ years since de-duped from #816 . 3 years since linked to #4232, and since then no maintainers from MS have commented or provided update on these two critical bugs. Are these things on any internal roadmap or associated with any project plan to be done in the next year? Or better yet, could you comment as to whether or not anyone is actively working on them?

7 years now...

[mikenunan]

I have just found my way here after spending an incredible amount of time trying to do what seems to be the most simple thing: set an env var globally inside of a distro or across all distros. ChatGPT thought it was possible to assign them in an [environment] section in /etc/wsl.conf or the system-level .wslconfig, which would indeed do the job nicely, but appears the bot was hallucinating that one.

Although this present issue is about bash specifically, for many use cases it would be helpful to have this not be shell-dependent. In my own case as a PowerShell-first user, the bash profile workarounds are not that helpful, and what should we do, define these things differently for every different shell type? In a corporate environment like mine we want to have a pre-configured distro with things like SSL config vars set up correctly, so that things work right out of the box without every dev having to configure their profiles.

The WSLENV workaround is about the only one that makes sense in that context, but is ugly as it means pushing profile changes to Windows desktops rather than just tailoring our WSL distro. The config sections suggested by ChatGPT would be dead simple to implement surely, and gets around any messing about with PAM etc. Can we have something like that, please please please???

[anodynos]

To celebrate 🎂 the 7 years anniversary of this issue in 10 days, I present you my workaround, based on @smaktacular 's one, that combines /etc/environment & your current $PATH set elsewhere (eg Windows Paths set by WSL, other export PATH in .bashrc/.zshrc etc):

At the end of your .bashrc or .zshrc add the following:

export PATH_TEMP=$PATH
while read line; do export $line; done < /etc/environment
# $PATH now is "/some/paths:/..." but we need to omit first & last chars (the quotes)
export PATH=$PATH_TEMP:${PATH:1:${#PATH}-2}
unset PATH_TEMP

Done - It took me a bit more than 7 minutes, it will take you a bit more than 7 seconds.

Happy 7 years anniversary! 🥳 🎆 🎈

PS:> Make sure you have a newline at the end of /etc/environment otherwise read line breaks ;-)

[bryndin]

7.5 years and ticking

This bug breaks snap on Ubuntu:

• Whatever packages snap installs get symlinked in /snap/bin
• /snap/bin is supposed to get into PATH via /etc/environment, and that is broken on WSL by this bug.

A simple fix is to add /snap/bin manually in .bashrc or .zshrc.

[dzciemix]

Workaround

$ cat /etc/profile.d/path.sh
export PATH="/opt/bin:$PATH"

[lucasfcnunes]

@dzciemix it worked!

[larsonmars]

Happy 8 years anniversary 🎂! Still breaks installations and scripts that assume /etc/environment is working, creating support overhead.