I have a script that exports an environment variable and starts some subscripts.
export LOGLEVEL="1"
/home/myuser/bin/myscript1.sh
/home/myuser/bin/myscript2.sh
LOGLEVEL is available to the processes started from the subscripts. How can I change the environment variable LOGLEVEL?
I have tried to set the variable with export LOGLEVEL="5" but that`s not working.
In general, you can only influence a process's environment variables at the time the process starts up. If you need to communicate a change to a running process, the environment isn't the right tool.
However, this question has some answers that suggest ways to overcome this limitation.
Edited to add in light of discussion in the question's comments: A fairly good way of communicating occasionally changing setup to a running process is to designate a configuration file where the LOGLEVEL value is set, send a SIGHUP to the process, and have the process reread the configuration file upon receipt of SIGHUP.
Related
I have a process which is supposed to use OpenMP, and I would like to verify whether an environment variable is set to the expected value.
I tried to read the environment variables of my program's process but can't find any OpenMP variable.
My question is: Can I see the OpenMP environment variable within my process with a terminal?
Is there a way to get an OpenMp status using a terminal?
Since you are seeing other environment variable but not the OpenMP ones, it could be because the environment variable OMP_DISPLAY_ENV is not set. If it`s not, then nothing will be shown.
I've always believed that environment variables live within the shell current user is logged into. However recently I've begun working on a shell of my own and learning more about how Linux works under the hood. Now it seems to me, that the environment is shell-independent and handled elsewhere (in the kernel?). So my question is how exactly does it work? Which part of the system is responsible for holding the environment?
Also for instance Bash makes the distinction between export-ed and unexported variables, the latter of which are not inherited by a subshell. Does that mean that each process is the system has it's own set of shell variables?
Yes each process will have its own set of enviornment.
You can find them at
cat /proc/<pid>/environ
How can one retrieve an updated environment variable once a node script is already running?
Consider the following gulp task. How can you update the environment variable Z (i.e., from some other script running on the system) so that the function outputs different values after it's running?
As is, environment variables set elsewhere are ignored and the function always outputs 'undefined'.
gulp.task('z', function () {
var z;
setInterval(function(){
z = process.env.Z;
console.log('Value of Z is: ' + z);
}, 1000);
});
Running Windows 7. I have tried both set and setx but nothing will persist into the running node script. I wouldn't think this is possible since you generally can't pass environment variables between command prompts without re-launching them (and using setx). But then again SO users are special and I've been surprised before. Is this even possible?
Yes it's possible. There are many options actually. You can pass variables between multiple scripts with 'inter process communication (IPC)'...
The easyest option is probably to do it via sockets, ie with use of redis. Advantage of this is that you can also use it to communicate between processes running on different devices, if this would be required in the future.
Another option is to do it via the built in process signalling:
https://nodejs.org/api/process.html#process_signal_events
There are many other options/library's with each their pro's and cons. For scalability you are probably best of when you do the communication via sockets, If performance is very important you can choose for an option which uses shared memory.
In this question are multiple options discussed;
What's the most efficient node.js inter-process communication library/method?
I use Terminal.app and iTerm, both of which support running multiple shells simultaneously via multiple tabs and multiple windows. I often use this feature, but as a result, if I want to change an environment variable setting, I generally have to run the same command once in every single tab and window I have open -- as well as any new tabs or windows that I open in the future. Is it possible for my shells to communicate with each other such that I can change an environment variable once, and have that change propagate to all my other currently running shells?
I know that I can statically set env variables in a startup file like .bashrc. I also know that I can have subshells inherit the environment of parent shells, either normally or via screen. Neither of those options address this question. This question is specifically about dynamically changing the environment of multiple currently-running shells simultaneously.
Ideally, I'd like to accomplish this without writing the contents of these variables to disk at any point. One of the reasons I want to be able to do this is so that I can set sensitive information in an env variable, such as hashed passwords, and refer to them later on in other shells. I would like to be able to set these variables once when I log in, and be able to refer to them in all my shells until I log out, or until the machine is restarted. (This is similar to how ssh-agent works, but as far as I'm aware, ssh-agent will only store SSH keys, not env variables.)
Is it possible to make shells communicate like this?
Right. Since each process has it's own copy of the environment variables, you can't magically change them all at once. If you bend your mind enough though, there are strange workarounds.
For instance, if you currently have a command you run to update each one, you can automate running that command. Check the bash man page for PROMPT_COMMAND, which can run a command each time the bash prompt is printed. Most shells have something similar.
As far as not putting a hashed password on disk because you are pulling it from an envvar instead of something like ssh-agent...that would be a whole 'nother topic.
Unless you write your own shell, you can't. ssh-agent works by having each SSH client contact it for the keys, but most common shells have no similar mechanism.
We have an stub that we are launching from inittab that execv's our process. (ARM Linux Kernel 2.6.25)
When testing the process it fails only if launched from inittab and execv'd. If launched on the command line it work perfectly, every time.
The process makes heavy use of SYS V IPC.
Are there any differences between the two launch methods that I should be aware of?
As Matthew mentioned it, it is probably an env variable issue. Try to dump yout env list before calling your program in both case - through the stub or 'by hand'.
BTW It could help a lot if you could provide more information why your program did crash. Log file ? core dump/gdb ? return value from execve ?
Edit:
Other checks: are you sure to pass exactly the same parameter list (if there are parameters)?
To answer your question , there is no differences between the 2 methods. Actually your shell fork() and finally call execve() to launch your process, feeding it with parameters you've provided by hand, and the environement variables you've set in your shell. Btw when launching your program through init it could launch it during an early stage of your machine startup. Are you sure everything is ready for the good running of your application at that point?
Could it be an issue of environment variables? If so, consider using execve or execle with an appropriate envp argument.
The environment variable suggestion is pretty good - specifically I'd check $PATH to make sure your dependent libraries are being found (if you have any). Another thing you could check is, are you running under the same uid/gid when run as inittab?
And if you replace your stub with a shell script ?
If it works from the command line, it should work from a shell script, and you can know wether it is your stub or the fact that it is in inittab.
Could it be a controlling tty issue ?
Another advantage of the shell script is you can edit it and strace your program to see where it fails
Was a mismatched kernel/library issue. Everything cleaned up after a full recompile.