Linux – Raise 128KiB Limit on Environment Variables

Is it safe to raise that value and what would be the consequences of a too high value?

Yes, it's safe to raise that value and below are the possible costs [source]:

• Each used inotify watch takes up 540 bytes (32-bit system), or 1 kB (double - on 64-bit) [sources: 1, 2]
• This comes out of kernel memory, which is unswappable.
• Assuming you set the max at 524288 and all were used (improbable), you'd be using approximately 256MB/512MB of 32-bit/64-bit kernel memory.
  • Note that your application will also use additional memory to keep track of the inotify handles, file/directory paths, etc. -- how much depends on its design.

To check the max number of inotify watches:

cat /proc/sys/fs/inotify/max_user_watches

To set max number of inotify watches

Temporarily:

• Run sudo sysctl fs.inotify.max_user_watches= with your preferred value at the end.

Permanently (more detailed info):

• put fs.inotify.max_user_watches=524288 into your sysctl settings. Depending on your system they might be in one of the following places:
  • Debian/RedHat: /etc/sysctl.conf
  • Arch: put a new file into /etc/sysctl.d/, e.g. /etc/sysctl.d/40-max-user-watches.conf
• you may wish to reload the sysctl settings to avoid a reboot: sysctl -p (Debian/RedHat) or sysctl --system (Arch)

Check to see if the max number of inotify watches have been reached:

Use tail with the -f (follow) option on any old file, e.g. tail -f /var/log/dmesg: - If all is well, it will show the last 10 lines and pause; abort with Ctrl-C - If you are out of watches, it will fail with this somewhat cryptic error:

tail: cannot watch '/var/log/dmsg': No space left on device

To see what's using up inotify watches

find /proc/*/fd -lname anon_inode:inotify |
   cut -d/ -f3 |
   xargs -I '{}' -- ps --no-headers -o '%p %U %c' -p '{}' |
   uniq -c |
   sort -nr

The first column indicates the number of inotify fds (not the number of watches though) and the second shows the PID of that process [sources: 1, 2].

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.