5

I have the following in my /etc/environment:

http_proxy=http://myproxy.net:12345

After rebooting the machine, I login and check the variable:

root@d6c44fa03243:/# echo $http_proxy
(empty)

Why is the variable not set?

Note: I must mention that this is a docker container, although I do not see why it would make a difference.

EDIT

More details about the system (Ubuntu 16.04.4 Xenial Xerus):

root@d6c44fa03243:/# uname -a
Linux d6c44fa03243 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

root@d6c44fa03243:/# cat /etc/issue
Ubuntu 16.04.4 LTS \n \l

EDIT2

According to the Ubuntu documentation:

/etc/environment

This file is specifically meant for system-wide environment variable settings. It is not a script file, but rather consists of assignment expressions, one per line.

  • Does it make a difference adding the line to /etc/profile? – nKn Mar 27 '18 at 8:57
  • 1
    @nKn I want it to be active system wide, not only for shell sessions (superuser.com/a/664237/94612). But before I even think about workarounds, I would like to understand what is going on. Why is /etc/environment not being evaluated? – dangonfast Mar 27 '18 at 9:02
  • According to this answer (superuser.com/a/664236): /etc/environment is not part of POSIX, it belongs to PAM (Pluggable Authentication Module), and only programs compiled with PAM support are able to use it (primarily login systems, which subsequently start the shell or user environment). This means it isn't even read by your shell.. – nKn Mar 27 '18 at 9:09
  • 1
    @nKn Which somehow contradicts This file is specifically meant for system-wide environment variable settings – dangonfast Mar 27 '18 at 9:15
2

Because UNIX tools are built with transparency in mind, you can find the answer with the help of grep. It doesn't matter if you are working with a full OS or a container (the later just means it you might have to take some extra steps to install tools you need for things to become transparent).

Check that you have grep installed on your OS and run sudo grep -R "/etc/environment" /etc/*. This will search all the system scripts and configurations to see which ones use use this file. On a default ubuntu/xenial64 vagrant box, the scripts and configurations that use this file are mostly in /etc/init.d/ /etc/pam.d/, and /etc/rc.*.d/.

The following configurations are how variables in /etc/environment get set in my shell:

/etc/pam.d/login /etc/pam.d/su /etc/pam.d/sshd

From man pam_env:

The pam_env PAM module allows the (un)setting of environment variables. ...

This module can also parse a file with simple KEY=VAL pairs on separate lines (/etc/environment by default). You can change the default file to parse, with the envfile flag and turn it on or off by setting the readenv flag to 1 or 0 respectively. ...

Do a similar search on your docker container. You can check if your container uses pam_env.so.

Most likely the best solution is to have your start up process create environment variables from /etc/environment but that advice is given without understanding what you are building. The uses in `/etc/rc*.d/ might be good examples for how to accomplish this.

Most people follow @ben-njeri's advice and set variables in the default configuration files for the bash shell.

  • This is an excellent answer. Doing sudo grep -r /etc/environment helped me figure out that I needed to modify /etc/pam.d/xrdp-sesman to have xrdp sessions read /etc/environment. – wisbucky Apr 18 at 17:39
0

Configure /etc/profile or ~/.bashrc or ~/.bash_profile files to export the variables whenever a new shell is started.

/etc/profile is for system-wide and others are for specific users.

Just add the lines like below at the end:

export http_proxy=”http://myproxy.net:12345”
export ftp_proxy=”http://myproxy.net:12345”
export https_proxy=”http://myproxy.net:12345"

So each time you start a shell, the variables are loaded and you can use them.

0

I have (had) this problem on Ubuntu 18.04. I couldn't get /etc/environment to work at all, but used a script in /etc/profile.d/ instead (as documented here), and that did work.

For more info, see my answer to this related question. Hope it helps :)

  • 2
    While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review – Dave M Nov 12 '18 at 13:20
  • @DaveM Please note that the essential part of the answer was included here, and that I'm linking to a StackExchange partner site. I've tried to make the answer a little more clear in terms of what worked, that the links are for more information, and added another link (heh). – bszom Nov 13 '18 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.