Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: cmd/go: build option to set env variable defaults #40870
Users are asking for a way to hard-code runtime environment variables, because their end-users cannot set them on app invocation.
I suggest a go build/test/run command-line option. Its use needn't be restricted to Go-specific variables. Existence of a variable in the environment at runtime would override any build-time default.
I considered a new stdlib API, but that opens the possibility of conflict between packages. A way to prevent that is to restrict the API to package
EDIT: fix example to use semicolon delimiter
If users are asking for this, it means we have failed at the way we configure programs.
On top of that, program configuration belongs in programs not on build command lines.
If the problem is bugs that can be disabled with GODEBUG settings,
In my case, I need to set values for "asyncpreemptoff" and "madvdontneed" for specific builds, no difference, is it "set on build" or "set by code".
As a develop, I want to be sure program runs the way I plan it, giving users ability to override that with environment settings.
These are called
It sounds like the real problem is that there are two runtime bugs that have not been adequately addressed, and too many people are working around them by setting GODEBUG settings. The two workarounds that are being overused are madvdontneed=1, for various perceived or actual out-of-memory conditions on Linux; and asyncpreemptoff=1, for various problems with spurious EINTR returns from Linux.
For madvdontneed=1, I believe the state of the world is as @aclements summarized in #33376 (comment). Go is doing the same thing as Java and Node here. It should not be necessary to set that. It is unfortunate that Linux tools like top/htop do not subtract out the lazyfree total from RSS in the display, but the OS knows what it can take away and will do that rather than OOM. That comment also says that container memory limits understand what Go is doing here too, so this should not be causing container OOMs either. If someone is seeing problems here, we need to get more information about their exact setup to help understand it better. Hence the (unanswered) questions to @elgatito above and more importantly on #37569. If there are other cases where using MADV_FREE is causing OOMs, please file details in a different issue and we will try to get to the bottom of that.
For asyncpreemptoff=1, the problem is that preemption has caused some (arguably buggy) kernel behavior returning EINTR where we weren't checking for it. And now I believe we are checking. If there are more places to check, let's fix those.
In both cases, fixing the specific bugs is more effective and will be easier than adding a new build option we will have to support for all time.
Let's fix the real bugs.