3 ms·
Changing the env during runtime is actually quite handy for debugging and forcing the program into specific states. Other than that, it can also be handy in k8
by withinboredom 3y ago
Changing the env during runtime is actually quite handy for debugging and forcing the program into specific states.
Other than that, it can also be handy in k8s with a VPA. You get more/less memory and then update the env to reflect that. Your service picks up the env change and updates the runtime.
IIRC, there is/was some way to listen to those changes in C#, and automatically update runtime settings.
- eqvinox 3y ago> Other than that, it can also be handy in k8s with a VPA. You get more/less memory and then update the env to reflect that. Your service picks up the env change and updates the runtime. You… can't change the env from outside the process… are you saying this is used by disjoint components within a single process? Or is this just a misunderstanding?
- withinboredom 3y agoYou can spawn as many processes as you want in a container, did you not know that? But you only need access to the /proc/pid directory to change another processes env.
- eqvinox 3y ago> But you only need access to the /proc/pid directory to change another processes env. /proc/$pid/environ is not writable (and as a matter of fact, due to how the environment works, it cannot be writable.)
- LegionMammal978 3y agoBut /proc/pid/mem is, if you like living dangerously! You'd just have to parse the dynamic-linker metadata to find where libc's environ is hiding. (Though statically-linked programs would be tougher.)
- SAI_Peregrinus 3y agoSpawning a new process doesn't require changing the parent's environment.
- pjc50 3y ago> You… can't change the env from outside the process… Not with that attitude you can't. (OK, without the joke: you can do this with an interactive debugger. But I think OP just meant "change it in the container and then restart the child process")
- rewmie 3y ago> Changing the env during runtime is actually quite handy for debugging and forcing the program into specific states. Most debuggers nowadays support altering variables at runtime after hitting breakpoints. In the meantime this was the very first time I ever heard anyone even considering changing env vars at runtime, let alone use it to debug stuff. Sounds like an ass-backwards way of going about debugging.
- riffraff 3y ago> Changing the env during runtime is actually quite handy for debugging and forcing the program into specific states. Wait, why would this need to happen at runtime? I have used env cars a lot to trigger specific cases but why would you want to do this while the process is running from within the process itself? If you control the process you can start it with the right env to begin with, no?