I just want to setup a system wide environment variable, JAVA_HOME for all users, including root user.


  • accessible to normal users
  • accessible to root
  • always loaded, not only for bash (gnome-terminal does not start a bash by default)
  • to work on Ubuntu, Debian and optionally Red Hat
  • great if addition could be easily scripted

For Ubuntu, and possibly other *nix platforms, add a new script in /etc/profile.d named java.sh, such as:

echo "export JAVA_HOME=/usr/lib/jvm/default-java" > /etc/profile.d/java.sh

Other considerations that were ruled out:

  • /etc/environment - works but is harder to maintain using other tools (or people will edit it); and
  • /etc/profile - same drawbacks as /etc/environment

On Debian/Ubuntu that would be /etc/environment

I don't know the Red Hat equivalent.

  • 2
    I believe /etc/environment is deprecated – Pat James Nov 25 '12 at 19:17
  • @PatJames do you have more info about this? I tried /etc/environment is is not loaded for root even after I rebooted the machine. – sorin Oct 30 '13 at 11:18
  • 1
    @SorinSbarnea some info is here: wiki.debian.org/Locale indicating /etc/environment is no longer used in newer releases – Pat James Oct 30 '13 at 17:52
  • 1
    That page only says that you shouldn't but locale related variables in /etc/environment. See also serverfault.com/a/584072/26218 – Flow Jul 30 '14 at 14:42

I don't understand why you ruled out /etc/profile. That is the correct location.


A few have answered saying that /etc/environment is depricated and/or not used in Debian anymore, and this is (as at version 7) false.

The file is actually read by PAM -- specifically, pam_env(8), via a default to the envfile flag. The manpage also states this default under the FILES section.

The wikis quoted (especially the locale one) merely state that locale-based environment variables are now meant to be in /etc/profile. Their statement "(in older versions of Debian, also /etc/environment)" is vague, and is in the context of locales.

A quick grep through /etc/pam.d shows:

root@box:/etc/pam.d# grep pam_env.so *
atd:auth        required        pam_env.so
cron:session       required   pam_env.so
cron:session       required   pam_env.so envfile=/etc/default/locale
login:session       required   pam_env.so readenv=1
login:session       required   pam_env.so readenv=1 envfile=/etc/default/locale
sshd:auth       required     pam_env.so # [1]
sshd:auth       required     pam_env.so envfile=/etc/default/locale
su:session       required   pam_env.so readenv=1
su:session       required   pam_env.so readenv=1 envfile=/etc/default/locale

Those config lines are additive, and as the first is missing envfile, it thus defaults to /etc/environment.

All of this, of course, relies on whatever binary you're using (crond, login shells etc) are compiled against PAM.

Finally, this implies that other systems using PAM (eg RedHat), behave the same, as can be seen in it's respective manpage.


/etc/enviroment is no used in the last debian stable release. The recomendation is create your own *.sh file in /etc/profile.d/ for this porpuose as Sorin S saids. See https://wiki.debian.org/EnvironmentVariables


One a side note: Have a look at the Modules Environment. I use this every time I have to offer a complex, versioned, self-extensible, concise UNIX environment to dozens or hundreds of users. It's mainly used on large scale multi-user HPC environments. Just using it for one particular variable is certainly over-engineering it, but it does an awesome job once you need more than a few software packages and their environment.


/etc/profile should work. I tested just now to be sure, put export SOMETEST=1234 to /etc/profile and after re-logging echo $SOMETEST gave me 1234 as expected. Also from gnome-terminal


You cannot use any ~ specific files in this case. so....

/etc/profile would be the proper place for it in this case. Current logged in users have to get a new login session though, but this should not be that big of a problem.

@wk01: /etc/profile is not loaded by a nonlogin shell by default. your .bashrc is probably loading it...

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.