strace Environment Variable Debug: Find What Process Reads (2026)

You’re trying to figure out which process is mucking with a specific environment variable, and strace is your tool.

The core problem is that environment variables are typically set when a process is forked and exec’d. When a parent process starts a child, it passes a copy of its environment to the child. If a process itself modifies its environment after it has started, it’s usually doing so through system calls like setenv or by directly manipulating environ. strace lets you see these system calls.

Here’s the breakdown of how to hunt down the culprit:

1. The Obvious (But Often Overlooked) - Shell Expansion

Before strace even gets involved, the shell itself might be expanding variables. If you’re seeing unexpected values, it’s often because the variable was expanded before the command you’re tracing even started.

Diagnosis: Run your command with env or printenv just before the command you suspect.

env MY_VAR=foo bar_command

Or, if you’re in bash:

echo "MY_VAR is: $MY_VAR"
bar_command

Fix: Ensure the variable is set correctly in the shell before executing the command. If it’s being set by a script, check that script.

export MY_VAR="correct_value"
bar_command

Why it works: This confirms that the issue isn’t with bar_command itself, but with how the shell is providing the environment to it.

2. Tracing setenv and putenv (for the process itself)

If a process is modifying its own environment after it has started, it’s using system calls. setenv(3) and putenv(3) are the common C library functions that ultimately call setrlimit or manipulate environ directly.

Diagnosis: Use strace to capture system calls, specifically looking for setenv and putenv related calls.

strace -f -e trace=setenv,putenv -s 1024 -o /tmp/strace.log your_command --args

Fix: Analyze /tmp/strace.log. You’ll see lines like:

12345 setenv("MY_VAR", "new_value", 1) = 0

or

67890 putenv("ANOTHER_VAR=some_other_value") = 0

The fix depends entirely on why the process is setting these variables. Is it expected behavior? Is it a bug in the application? You might need to reconfigure the application, fix its source code, or prevent it from running if it’s an unwanted modification. Why it works: This directly shows if the process is attempting to change its own environment after initialization.

3. Tracing execve (for child processes)

When a process starts another process, it passes its environment to the new process via the execve(2) system call. If a child process inherits an incorrect environment variable, it means the parent process passed it incorrectly.

Diagnosis: Trace execve and inspect the environment passed.

strace -f -e trace=execve -s 1024 -o /tmp/strace_execve.log your_command --args

Fix: Look for lines in /tmp/strace_execve.log that show execve being called. The arguments to execve include the environment array (often the last argument, envp).

12345 execve("/usr/bin/some_child_process", ["/usr/bin/some_child_process", ...], ["MY_VAR=wrong_value", "PATH=/usr/bin:/bin", ...]) = 0

The fix is to identify the parent process that made this execve call and correct the environment it’s passing. This often means debugging the parent process. Why it works: execve is the fundamental system call for replacing a process image with a new one, and it explicitly takes the environment array as an argument.

4. Checking the environ Pointer Directly (Less Common, More Advanced)

For processes that are really doing low-level manipulation, they might be directly modifying the environ global variable in C. This is less common than using setenv or putenv but possible.

Diagnosis: This is harder with strace alone. You’d typically combine strace with a debugger like gdb.

1. Start your command under strace: strace -f -o /tmp/strace.log your_command --args
2. In another terminal, find the PID of your process (e.g., pgrep your_command).
3. Attach gdb: gdb -p <PID>
4. Set a breakpoint on setenv or putenv if you suspect those, or more generally, try to find where environ is being written. You can inspect environ in gdb with p environ. To see what it points to: p *environ. Fix: If you find direct manipulation of environ, it’s almost certainly a bug in the application. The fix would be to correct the application’s code. Why it works: This allows you to inspect the process’s memory and see the actual environ pointer and its contents at runtime.

5. File Descriptors and Shared Memory (Extremely Rare for Env Vars)

In highly specialized scenarios, environment-like information might be passed via file descriptors or shared memory. This is not how standard environment variables work, but if you’re dealing with inter-process communication mechanisms that mimic environment variable passing, you might need to trace file descriptor operations.

Diagnosis: Trace read, write, sendmsg, recvmsg, mmap, shmat.

strace -f -e trace=read,write,sendmsg,recvmsg,mmap,shmat -s 1024 -o /tmp/strace_ipc.log your_command --args

Fix: Analyze the traced data for patterns that resemble environment variable assignments. This is highly application-specific. Why it works: This casts a wider net to catch non-standard IPC mechanisms that could be used to convey configuration data.

6. The Real Culprit: Systemd or Init Scripts

Often, the environment a process sees is dictated by the service manager (like systemd) or traditional init scripts. These managers set up the environment before launching the service.

Diagnosis:

• Systemd: Check the service unit file (e.g., /etc/systemd/system/your_service.service). Look for Environment= or EnvironmentFile= directives. Also check files specified in EnvironmentFile=.
• Init Scripts: Examine /etc/init.d/your_script. Look for export commands or sourcing of other configuration files. Fix: Modify the relevant systemd unit file or init script to set the environment variable correctly. After modifying a systemd unit, run sudo systemctl daemon-reload and then restart the service. Why it works: These service managers are responsible for launching your process with a specific, controlled environment.

The Next Hurdle

Once you’ve traced and fixed the environment variable issue, the next problem you’ll likely encounter is that the process now starts correctly but fails due to a different configuration setting that was also incorrectly passed or interpreted.