Should we filter this out from sub-process envs (i.e. when we launch shells)? It probably doesn't matter for correctness, more of a cleanliness thing.

We could also addCODER_AGENT_PID as part of the sub-process envs for programmatic use (e.g. to enable pprof,kill -USR1 $CODER_AGENT_PID). We'd need to do that always though, not only when forking.

I agree that it's certainly cleaner to filter it out. The only reason I didn't is because I did not want implementation details of thereaper package to leak outside. In other words, if you're developing the agent I don't want people to have to think about using a special function that filters out arcane environment variables that you don't understand.

I think if it becomes an issue we devote some time to figuring out something unobtrusive.

I already merged this but I think a cleaner solution is to have a--noreap flag that we append to the forkexec cmd. Then we don't pollute subprocess envs or leak to the world whats happening under the hood. What do you think@mafredri

That makes sense and I agree that's a clean solution@sreya. 👍🏻

Any reason to limit this tolinux only? I suppose this should work on Darwin and other BSD flavors too?

It was causing things to fail when it ran on macos. I don't think limiting it tolinux is going to be a big deal because the reaper is primarily going to be used for docker containers and on mac that's going to be run in a linux vm anyway.