There is a really strange situation in my Ruby-based processes: their /proc/self/environ is really broken. For some reason, the ENV inside Ruby looks fine but I'd like to understand what's going on.

Processes are started using bundle exec, for example bundle exec sidekiq. The end result is that the /proc/<pid>/environ file only contains a couple of bytes (usually 4) of the invoked command plus a bunch of zeroes. In the example above, the environ file would look like

$ sudo hexdump -C /proc/2613895/environ
00000000  65 6b 69 71 00 00 00 00  00 00 00 00 00 00 00 00  |ekiq............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000390  00 00 00 00 00 00 00                              |.......|
00000397

When invoking another command line, for example a rake task, the environ file would contain the last couple of characters of the rake task name.

Since the environ file cannot be modified by the process itself after it starts, it must have been set by whomever made the execve call but I am stupefied who might be responsible and why.

This seems to mostly happen when processes are started through systemd, but none of the other processes started by systemd show the same behaviour; only the ones started through bundle exec so I'm thinking that it's not related to systemd.

CodePudding user response：

The /proc/$pid/environ file normally only contains the environment passed to the process when it was created. It does not reflect any changes to its environment the process may have made after it began execution. Furthermore, it simply exposes the portion of the stack of the process which contained the original env vars. If the process modifies those stack locations that will be reflected in the content of that procfs file. See, for example, https://unix.stackexchange.com/questions/302948/change-proc-pid-environ-after-process-start.

I would complain to the Ruby team since they shouldn't be stomping on the original env var stack locations.