Why does environment variable persistence break the PATH var?

Question

I tried to persist the environment variables for ORACLE in RedHat using /etc/environment.

It cleared my PATH variable; no command was recognized afterwards.

Why does it happen, since just executing the same commands in the shell just works fine?!

The contents of my /etc/environment:

ORACLE_HOME=/usr/lib/oracle/12.1/client64
PATH=$ORACLE_HOME/bin:$PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib

Answer 1

/etc/environment is a configuration file for pam_env, not a file read by a shell. The syntax is somewhat similar, but it is not the same. In particular, you can't refer to existing variables: you've set your search path to contain $ORACLE_HOME/bin and $PATH, i.e. directories with a dollar sign in their name.

To set variables for all users, you can edit /etc/security/pam_env.conf, which has a different, richer syntax, but still not as rich as what you can do in a shell.

ORACLE_HOME DEFAULT=/usr/lib/oracle/12.1/client64
PATH OVERRIDE=/usr/local/bin:/usr/bin:/bin:${ORACLE_HOME}/bin
LD_LIBRARY_PATH DEFAULT=$ORACLE_HOME/lib

Note that you can refer to other variables, but you can't refer to a variable's previous value.

If you want a more flexible approach, add the variable definitions to /etc/profile instead. There you can use all shell constructs. The downside is that this is only read in login sessions, not e.g. by cron. You can easily benefit from them by adding . /etc/profile; at the beginning of your cron jobs however.

export ORACLE_HOME=/usr/lib/oracle/12.1/client64
PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib

Answer 2

The assignments in /etc/environment should be exported. Otherwise their values are not used. If you use "." to source a file, then you would use this syntax:

export ORACLE_HOME=/usr/lib/oracle/12.1/client64
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib

But as noted, /etc/environment is not intended to be sourced (see for example Persistently set the value of an environment variable for all users).

According to 6.6. pam_env - set/unset environment variables (The Linux-PAM System Administrators' Guide):

The pam_env PAM module allows the (un)setting of environment variables. Supported is the use of previously set environment variables as well as PAM_ITEMs such as PAM_RHOST.

By default rules for (un)setting of variables is taken from the config file /etc/security/pam_env.conf if no other file is specified.

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.

Since setting of PAM environment variables can have side effects to other modules, this module should be the last one on the stack.

That is, PAM (which authenticates users) reads that file, and it appears that if it does not understand the value which you set, will set the variable to nothing.

If instead you had modified /etc/profile, you would have gotten better results. But reading the comment at the top of the file:

# /etc/profile

# System wide environment and startup programs, for login setup
# Functions and aliases go in /etc/bashrc

# It's NOT a good idea to change this file unless you know what you
# are doing. It's much better to create a custom.sh shell script in
# /etc/profile.d/ to make custom changes to your environment, as this
# will prevent the need for merging in future updates.

you would get even better results by creating a /etc/profile.d/custom.sh file with your settings.

However, you can get into trouble with that LD_LIBRARY_PATH setting. Instead, you should add the directory to the configuration via /etc/ld.so.conf.d, e.g., as a file, e.g., /etc/ld.so.conf.d/oracle containing the path:

/usr/lib/oracle/12.1/client64/lib

Further reading:

• Setup a Global User Profile with ‘/etc/profile.d/custom.sh’
• How to not run /etc/profile.d/custom.sh during Secure FTP login