8

I am using Ubuntu 9.1 (Karmic Koala) on my server.

A simple matter of setting environment variables so that they are globally available across all processes is driving me crazy and I'd appreciate some help!

I've tried setting them by using the export command in several different 'usual suspect' locations such as .bashrc, .bashrc, .profile. These work great for the shell itself and processes forked off the shell but not for processes started outside the shell (for example daemons kicked off at boot time or particularly annoying for me is that Mongrel launched by Capistrano doesn't seem to have these variables set and hence Ruby doesn't have access to them).

I've also tried some crazy ideas like setting them in a shell script and calling this script during boot time (via the update-rc.d method) to no avail.

In Windows, one can simply define a "system variable" which becomes available across all processes in the OS. How does one do this in Linux; specifically Debian based OS?

Improve this question
4
  • This isn't really a programming question, so I'm voting to migrate.
    – David Thornley
    Feb 22, 2010 at 15:10
  • 1
    As asked this question is meat for Super Users, but we don't yet know what the underling problem is...I get the feeling that bhavinb is trying to patch together a solution, and the right approach might yet be a programming topic. YMMV.
    – dmckee --- ex-moderator kitten
    Feb 22, 2010 at 15:19
  • ...10 hours and no further explanation, I'm for sending this on.
    – dmckee --- ex-moderator kitten
    Feb 23, 2010 at 2:09
  • thanks for migrating this question. This is indeed a better place for such questions
    – bhavinb
    Feb 23, 2010 at 13:47

3 Answers 3

Reset to default
6

Processes (including shells) only inherit variables from their parents. There is no way to change them from the outside thereafter.

Set "global variables" as early in the boot (for system processes) or shell invocation (for user processes) as possible, or resign yourself to setting them in multiple places.

This may seem like a pain, but the ability to change another processes environment would be a bug, and would introduce all kinds of nasty race conditions.

What are you trying to do that you want "global" environment variables? There may be way to work around your problem.

Workaround:: Write a minimal script in your favorite shell format that only sets the variable you want and put it in a globally accessible place:

/etc/loglocaltion.sh:

export MY_LOG_DIR=/opt/share/mylog
export MY_DEFAULT_LOG_LEVEL=URGENT

and for everything that you want to use that configuration do one of

  1. launch it from shell which has sourceed loglocation.sh in it's non-interactive login file (the one that gets read for all instances of the shell, i.e. .bash_profile).
  2. write a minimal wrapper script which sources loglocation.sh before launching the real program. launchcorelogger.sh:

 

 CORELOGGER=/opt/sbin/mycorelogger
 source /etc/loglocation.sh
 exec $CORELOGGER

and have init run the script.

Now edits to the loglocation script will effect all associated processing if your run them from a fresh shell in the first case or restart them using you systems dameon restarted (/etc/init.d/mycorelogger restart or whatever).

Improve this answer
3
  • I am not trying to modify env variables inside a process. I just want to make a bunch of settings available across disconnected applications that I have created. For example, if you have 3 different apps all logging to a $MY_CUSTOM_LOG_LOCATION folder, then having this variable defined such that it is available 'globally' makes sense. If all 3 processes are launched from a shell, then setting this variable in .bashrc works but if one of them is a daemon kicked off at boot time, then that process does not see the variable being set in .bashrc.
    – bhavinb
    Feb 23, 2010 at 13:46
  • Exactly what I am trying to do is set a few variables that point to different folders used by applications and scripts. For example, one such folder points to where my webapp is deployed on the server. This is then used across different applications such as Stunnel daemon, Rsync configuration file, Bash scripts that are called by my Ruby-on-rails webapp (which incidentally doesn't see the variables because the Mongrel app-server that forks ruby gets spawned over ssh and is not started over a logged-in terminal session. If I start Mongrel from a shell on the server, ruby sees the variables).
    – bhavinb
    Feb 23, 2010 at 13:55
  • The proposed solution works great! However, this is not exactly what I was hoping. This still means that system daemons such as CRON, SSH both of which I am using to execute scripts/commands that rely on my custom variables will not work. Suppose I want to execute a command over SSH saying 'less $CORELOGGER/Masterlog', it will not work unless I source my loglocation.sh wrapper before EVERY daemon including system daemons gets initialized. Bit painful this.
    – bhavinb
    Mar 4, 2010 at 13:42
2

I propose putting your env vars in /etc/environment. Mine currently contains

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
NUKE_PATH=/spr/studio/codebase/nuke

and NUKE_PATH is set for cron processes and Bash shells.

(Sadly, not for processes started by Deadline, a process queuing app, but that's my problem not yours :-)

Improve this answer
1

This article helped me: https://help.ubuntu.com/community/EnvironmentVariables

Essentially, /etc/environment is good for system-wide variables and .sh files under /etc/profile.d/ will be run whenever someone logs in via the console or over ssh.

Improve this answer
2
  • Yes, but he explicitly mentiones he's not aiming only for console/ssh, but other processes as well.
    – Djumaka
    Jul 31, 2020 at 10:28
  • 1
    Yes, and that's why I said to use /etc/environment...
    – lane
    Jul 31, 2020 at 14:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .