Environment Variables – Are 184 Too Many?

environment-variablesprofileqnx

I am trying to find the cause of some OS wonkiness, and am concerned about environment variables.

The software I have been handed puts an incredibly high amount of environment variables into the user's .profile.

When I type set | wc the result is 9571 bytes long! There are 184 entries. To me, this seems inordinately large, but I don't have anything explicit to point at and say "this is wrong because xyz".

I see nothing in the ulimit documentation that speaks about environment variable total size, but am concerned. I'm not worried about overall memory utilization (there's enough to do what I need), but I am worried about overrunning some internal limit and causing odd behavior in the OS (probably not germane to the question I'm asking, but the "odd behavior" is that shared memory queues are not giving me back all the data I put in on the other end. I'm getting around 5% out).

Every single script that starts up, every single shell that is run, and every single binary that runs gets a full, individual copy of the environment variables, and I think 9k is too big. Should this be a worry, or am I concerned over nothing?

I'm running on an embedded x86 QNX 6.4.1 Neutrino system with half a gig of RAM.

Best Answer

When I type set | wc the result is 9571 bytes long!

Assuming you got that number correct, it is in fact quite small, probably because you are using QNX. On a normal desktop system, it is much larger. Here's what I get on fedora 20:

> set | wc --bytes
133195

133 kB. I did not count the entries as many of them are sourced functions (git seems to install a lot of these), but I did skim them over and there doesn't seem to be anything untoward. A few kB at most is from custom stuff by me.

I am worried about overrunning some internal limit and causing odd behavior in the OS

I very much doubt this is possible because a lack of bounds checking there would indicate a very significant bug in the implementation -- preventing someone from just writing a long variable to inject data into memory has to have been a basic concern. Beyond that, as you say, 9kB is nothing memory wise. I would presume lookups on these are done with a hash table, so the number of entries would not impair performance.

Related Solutions

Bash – ssh user@IP sh missed environment variables

You shouldn't have environment variable definitions in ~/.bashrc, that file is for configurations for bash when running interactively (aliases, prompts, that kind of stuff). The place for environment variables is ~/.profile; it's read when you start an interactive session in text mode, and on many systems also in graphics mode. See this answer for more details.

To run a bash shell that sets your environment variables as usual for the remote machine, you can do

ssh user@IP bash --login runme.sh

For other shells, make them read your .profile (and perhaps /etc/profile as well):

ssh user@IP '. /etc/profile; . ~/.profile; exec runme.sh'

If you want to copy environment variables from your local session over ssh, that's possible but usually disabled on the server side. Read this answer for more details.

Shell – Protected environment variables

The environment is a list of strings of the form var=value (by convention) that is passed as the 3^rd argument to the execve() system call.

That list is put somewhere on the stack of the process when it starts to execute the new command just like for the list of arguments (another list of strings passed as the second argument to execve()).

In programs using the libc (most), an initialisation code called before the main() function is invoked, makes those environment strings available as the environ array.

The libc also provides with putenv and setenv functions that can modify (a copy of) that list that the program received. That maintained, modified copy will then be passed to the next command executed by the process or any of its children via the execvp()/execl()/system()/popen()... functions of the libc (which themselves end up calling the execve() system call).

Now while when you build up a list of strings that you pass manually to the execve() system call, you may pass strings like foo (without a = character) or =bar (with an empty variable name), setenv won't let you do that (setenv("", "bar", 1) is rejected).

setenv("a=b", "c") will also be rejected. So the strings that will be defined by setenv will always be of the format x=y where x may not be empty.

That's about the only restriction (also applied by putenv). Well those being NUL terminated strings, of course the NUL character cannot appear in the variable name or value.

setenv("*", "x", 1), or setenv("\n\n", "", 1) are all OK as far as setenv() or the kernel are concerned. Now, whether you're going to be able to do anything useful with those is another matter.

Best Answer

Related Solutions

Bash – ssh user@IP sh missed environment variables

Shell – Protected environment variables

Related Question