Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

A system service started by systemd does not automatically import /etc/environment. That file is commonly read by PAM’s pam_env module during certain login flows, which can make a variable show up in a terminal even though the service never receives it. Set variables on the systemd unit that needs them; user services use a separate mechanism.

Why a variable works in your terminal but not in a service

Several components can set environment variables, and they operate at different times and scopes. A login application may use PAM to establish a session; a shell may then set or modify its own variables. Separately, systemd’s system manager starts system services, while a user manager starts that user’s services. A value being present in one environment does not mean another manager or process receives it.

The Linux-PAM pam_env(8) manual says that pam_env reads /etc/environment by default as simple KEY=VAL pairs. But the module must be included in the applicable PAM stack and invoked through a flow that opens a session or sets credentials. The manual notes that it does nothing when called only by pam_authenticate(). Whether a particular login path reads the file therefore depends on that system’s PAM configuration and the application’s behavior.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

A system service is started by systemd’s system manager, not by your login session. It does not automatically inherit arbitrary variables from /etc/environment or from a user’s shell. The systemd project describes its approach in systemd.exec as providing a “small curated list of environment variables” to processes; it discourages importing every variable from a graphical session or shell.

How to set variables for one system service

For a single unit, use a unit drop-in with either Environment= for a value written directly in the unit or EnvironmentFile= for assignments kept in a separate file. A dedicated file keeps service configuration scoped to the service instead of relying on a global file that the service manager does not import.

Use a dedicated environment file

  1. Create the file, for example /etc/example-service/environment, with newline-separated assignments:

    MODE=production
  2. Open a drop-in for the service:

    sudo systemctl edit example.service
  3. Add the following unit configuration:

    [Service]
    EnvironmentFile=/etc/example-service/environment
  4. Save and close the editor, then restart the service so its process is launched with the updated configuration:

    What’s actually slowing this PC down?

    Pick the symptom - the matching free tool is one click away.

    Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
    sudo systemctl restart example.service

EnvironmentFile= uses a text file of assignments; it does not run the file as a shell script. Do not rely on shell features such as command substitution or shell startup behavior. The systemd systemd.exec manual documents the assignment syntax and execution behavior; check the installed manual on the target host because available features and details can vary with systemd version.

Set a value directly in a drop-in

For a small, non-sensitive value, you can put it in the unit instead:

[Service]
Environment=MODE=production

After changing a unit drop-in, restart the service to make the running process receive the new environment. systemctl daemon-reload makes systemd reread unit files; it does not import /etc/environment into the manager’s environment.

Keep credentials out of ordinary environment assignments

Environment variables are not a safe default for passwords, tokens, or other secrets. The systemd execution-environment documentation warns that unit environment variables may be exposed to unprivileged clients and points to credential directives for sensitive data. Consult the installed systemd.exec(5) documentation for credential options supported by your systemd version.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How user services differ

A systemd user manager has its own environment configuration. Files under ~/.config/environment.d/ can configure variables exported by that user instance to services it starts. Applicable system-wide environment.d directories can also provide configuration. This is a user-manager mechanism, not a way to configure system services.

The systemd project documents the mechanism in its environment.d manual. After changing a file, the manager and services may need reloading or restarting depending on when the value is consumed. A service that is already running will not have its process environment retroactively changed.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Which configuration mechanism fits?

Mechanism Scope and timing Use it for
/etc/environment via PAM A PAM-mediated login or session flow, if the relevant stack and application invoke the module appropriately Values intended for qualifying login sessions; not automatic system-service configuration
Environment= in a unit A specific system service when systemd starts its process A small, non-sensitive value used by that unit
EnvironmentFile= in a unit A specific system service; the file is read shortly before the process executes Several service-specific assignments kept outside the unit file
environment.d Services started by a systemd user manager Variables intended for that user manager’s services
locale.conf System-wide locale configuration, read early at boot Locale settings, not arbitrary service-specific variables

Systemd’s locale.conf manual describes the locale-specific role of that file. It is not a general-purpose replacement for a unit’s environment settings.

How to verify what a service receives

First identify which manager starts the process. For a system service, inspect the unit and its drop-ins; for a user service, inspect the user unit and its manager’s environment configuration. Then verify the environment from the process that actually runs the workload, or use an appropriate minimal diagnostic command for the service.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The systemd execution-environment documentation gives systemd-run -P env as a way to inspect the system manager’s environment and systemd-run --user -P env for the user manager. These show what the respective manager provides to a transient command, not necessarily every detail of an individual service’s final environment, which can also be affected by that unit’s configuration.

Version and distribution caveats

PAM stacks and systemd builds vary by distribution, and the upstream systemd manuals are rolling documentation. Check the installed systemd.exec(5), environment.d(5), and the PAM service file for the login or application path in question. The key distinction remains the scope: PAM may set up a login session, but a system service needs its environment configured through systemd’s unit settings.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.