Wrong conclusion - ability to change the process environment from outside the process.
Let's say you run a
This starts a bash shell instance with environment vars, in which the ruby interpreter starts inheriting the current bash shell instance environment and maybe adding some interpreter specific new env vars.
Each running program gets a
process id aka
The process environment is stored in
/proc/<pid>/environ which is read only and can't be changed from outside - as pointed out here change environment of a running process
While your ruby script is running the parent bash instance is running, too. This bash instance is not reading changed env vars and is not inheriting or propagating new vars to it's child :
$ pstree -p | grep ruby
you can grep for your env.vars with
xargs -n 1 -0 < /proc/5678/environ | grep MYVAR
The only way to have the new changed environment vars while the script was running is to start a new bash/ruby instance and exit the old one.
Possible wrong conclusion - script reads constantly from env - script gets notified when env has changed - env is not beeing cached by the interpreter.
Usually a script initializes reading env vars. when starting the script only, and keeps using internal vars at runtime not env_vars. Even if changeing the process env from outside were possible, and the script reads constantly the environment vars - the env could be a cached copy and not the real deal.
key = os.environ.get('MYVAR')
# do something with key until scripts ends
- Modify the ruby script to execute
openssl rand -hex 32 and read the result to the variable from time to time.
- Modify the ruby script to read a file
/path/data into a variable generated by cron with output from
openssl rand -hex 32 from time to time.
- A cronjob restarts the script with the new environment. (ie. with
sudo # see switches -i -u and --) as mentioned in the comments user wide env could be set in profile.d what-do-the-scripts-in-etc-profile-d-do