0

In most *nix environments using bash, you'll change environment variables that are local to your user in ~/.bash_profile or a similar file and then source the changed file in order to make the changes effective in your session.

Similarly, sourceing /etc/profile after a change will make those changes effective in your current session.

But suppose you need to change an environment variable that is defined in /etc/profile (or somewhere under /etc/profile.d/) and want the change to be visible across all sessions of all users on the system immediately. How can you achieve that without rebooting the system?

Improve this question

2 Answers 2

Reset to default
5

You could force all logged in users to logout and then login again (and kill & restart any daemon processes which happen to be started by a shell which uses /etc/profile). Rebooting isn't required.

Other than that, you can't.

All you can do is source /etc/profile individually in every shell session that needs the new definition....but that can only affect shells you can actually run source /etc/profile or . /etc/profile in - you can't, for example, directly change the existing environment of an already running process (e.g. a running X session).

Child processes can't change their parent process's environment. Not directly, anyway (a parent process could watch what its children do and take actions based on that, including changing its own environment...but that's an entirely different thing, and one that would need to be programmed into the parent process)

Improve this answer
2
  • Could you do some horrible hacky thing like somehow mounting /proc rw and then injecting something into all /proc/$PID/environ files? Would that even be possible? Pretty sure it would be a bad idea in any case. Commented Dec 14, 2021 at 11:48
  • 1
    probably not. /proc/$PID/environ's perms are 0400, readonly (and only by owner). can't be changed by chmod, either - which is not at all surprising. you would have to hack the kernel to add write capability to it, and even then there's no guarantee that adding or changing a variable in it would have any effect. most programs read from env only once, at startup, and then either use and discard the value or copy it to an internal variable. it's much easier (and much saner) to just restart any programs with the desired env when you need to. Commented Dec 14, 2021 at 12:06
2

You don't, really.

And the reason for that is that while the environment variables are passed to the program when it's executed (the same way command line arguments are), after that they're just some table somewhere in the memory of the process. You can't modify them from the outside, from a another process, because in general you don't know where they are.

The C library keeps a pointer called environ, which points to a table of pointers to the values that are together called "the environment". The location of that table might change if it needs to be reallocated during the lifetime of the program, and the locations of the values would similarly change.

The environ pointer itself would live in the same location for the time the program runs, so you could plausibly hack the values, provided you find the pointer. Stuff like address-space layout randomization would cause it to be in different locations in different program invocations. Even if you were to find it and change the program's memory, you can't tell if the program copied the value (or a pointer it) somewhere else and used it from there. Like stuff from a configuration file would be copied to some place within the program memory.

On the system call level, the environment doesn't even get automatically copied across the execution of a program, since the environment values have to be explicitly passed as an argument to the execve() system call, and the table passed there doesn't need to have any relation to what the executing process calls its environ.

All of that also means that what e.g. /proc/$pid/environ shows in Linux might not correspond with what the getenv() system call returns within the program. (I think the file shows the area of memory that was used to pass the values when the program was executed.) The idea of there being "the environment" as some special data structure is not exactly right.

To modify the configuration of a running program you'd need support from the program itself, it'd need to be able to reload the configuration from somewhere. Or at least support from its parent, which could reload its configuration, and restart the child to pass it another set of environment variables.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.