Score:1

Ubuntu

Using files in /etc/environment.d

Jonathan

3/12/24, 6:35 PM

I am trying to setup a brand new installation of Ubuntu 22.10. I need to make some environment variables globally available. I have read in the Man pages that the correct way to do this is to provide a file in the /etc/environment.d directory with a name like 90-myfile.conf. When I try this, the environment variables are not established. If, instead, I put the variable definition into /etc/environment it is picked up. Is there something additional that I need to do? Using a command processor such as bash is not on because the variables need to be globally available.

443

1 + 7

environment-variables

environment

user10489

3/12/24, 6:57 PM

"global" is very slippery. Exactly what context do you need these variables to be set?

Jonathan

3/12/24, 6:59 PM

Every possible context that can make use of environment variables.

user10489

3/12/24, 7:03 PM

I don't think there is a single "global" context. There are multiple global contexts, and each gets environment variables from a different source. You need to be specific. Or at least make a list. Some contexts even reset environment variables to remove "global" ones.

Jonathan

3/12/24, 7:08 PM

My understandinfg has been the the environment variables defined in /etc/environment and in environment.d are the global conttext that gives a starting point for every other environment. As for systemd, I find varying comments about its use of environment.d, but little that seems authoritative, I also find comments stating that all user provided environment variables should be placed in environment.d

user10489

3/12/24, 7:25 PM

Nearly every one of those statements is wrong.

Jonathan

3/12/24, 7:43 PM

It turned out to be a permission problem with the files going into environment.d Group and Other needed read access.

azernik

7/25/24, 8:10 AM

@Jonathan - could you add this as an answer and then mark it as the correct one? Makes it much easier to find.

Score:1

Ubuntu

user10489

3/12/24, 7:42 PM

In unix, the environment is passed from a parent process to a child process. The parent process has complete control of the child's initial environment. By default, the child inherits the parent's environment, but the parent can pass something completely different, and the child can change it afterwards. As such, there is no "global" environment. There is an "initial" environment, but no global environment.

So, if nothing is explicitly set, the environment is inherited from whatever parent process last set it before forking.

Every operating system (and every distro) handles setting the initial environment differently. Since this is asking about Ubuntu, I'll limit things to that.

In Ubuntu, systemd starts the first processes, and has control of that initial environment. Systemd chooses to not have a way to set a global default environment within itself, but it has provisions for setting variables in different contexts.

systemd-environment-d-generator sets initial environment for user manager instances.
systemd.environment-generator has separate config files for each manager service
pam_env.conf modifies the environment for users that log in (see man pages for environ(7) and pam_env.conf)
For bash and sh, /etc/environment can set variables when the shell starts; these can be inherited by subprocesses. Most shell instances read this, but some don't, and they can be explicitly told not to.
Each shell can read /etc/profile or /etc/bash.bashrc which in turn may read files from /etc/profile.d, but again, not every shell instance does this, and the shell can be told to not read these or only read these.
Each user's shell init files can modify the environment.
Programs like ssh and sudo have whitelists and blacklists of variables that are intentionally inherited or intentionally removed for subprocesses.
Services like systemd and cron typically inherit and pass a very minimal set of environment variables. Cron allows setting variables in each config file that are "global" for that config file.
The env command can modify the environment of a command before it is started.

This list is not exhaustive, there are probably more sources. And none of these are "global" -- environment variables are explicitly local to each process, although they can be inherited from a global source.

+ 2

Jonathan

3/12/24, 8:18 PM

I was using "global" in the same way that you are using "initial" to describe an initial set of environment variables. If the ones that I set are not presented, then I will have to look at the requirements of that specific environment. But putting environment variables into environment_d will ensure that user supplied variables are supplied to most processes that run in login shells.

user10489

3/12/24, 8:21 PM

Yes, that's why I included the sources for the initial environment. That's about as close as you get to "global".

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Using files in /etc/environment.d

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.