Persist Environment Variables in Linux

Learn how to set environment variables so they survive logins and reboots.

16.11.2025 | reading time: 3 min

Every new shell starts with a fresh set of environment variables — how do you make a variable stick? This short guide shows concrete steps to persist variables for a single user, for the whole system, and for services so the value is available after logouts and reboots.

Hands-on: Add a user and a system variable

Do this now: append an export to your shell file, reload, and confirm the value. ```bash echo 'export MYAPP_HOME="/opt/myapp"' >> ~/.bashrc source ~/.bashrc echo $MYAPP_HOME ``` For a system-wide setting create a small script under /etc/profile.d and test with a new login: ```bash sudo tee /etc/profile.d/myapp.sh > /dev/null <<'EOF' export MYAPP_HOME="/opt/myapp" export PATH="$PATH:$MYAPP_HOME/bin" EOF ``` Open a new session or reboot and the variables appear for all interactive logins.

Background information

On many distributions /etc/environment is parsed without a shell, so constructs like "$PATH" or command substitution do not work there. Historically PATH management predates modern shells and was one of the earliest ideas to control where executables are found. Service managers like systemd introduced their own environment handling to avoid relying on interactive shell files.

related commands

systemd set-environment
direnv
profile.d scripts

Watchouts, gotchas and good habits

Know the differences: ~/.bashrc is for interactive shells, ~/.profile or ~/.bash_profile run at login, and /etc/environment is a simple KEY=VALUE file that does not support shell expansions; use /etc/profile.d for export scripts instead. Avoid repeatedly appending PATH entries by checking first, prefer `PATH="$MYAPP_HOME/bin:$PATH"` to prepend, and for variables used by daemons manage them via systemd unit Environment= or EnvironmentFile to ensure service processes see the values.

Where system tools fit in

Use `printenv` or `env` to inspect variables, `export` to set them in a shell, and `systemctl set-environment` or unit files to provide variables to systemd-managed services; consider direnv for per-project environments and /etc/default for older SysV-style services.

Finish line and next steps

You can now persist variables where they belong: user files for interactive shells, /etc/profile.d for system logins, and systemd or service files for daemons; practice these on a test VM and then explore how login shells and non-login shells differ. Keep learning Linux fundamentals and consider formal certification study such as CompTIA Linux+ or LPIC-1 with intensive exam preparation at bitsandbytes.academy to deepen practical skills.

Join Bits & Bytes Academy First class LINUX exam preparation.

setup scripting boot-process processes troubleshooting