4 ms·

I am not a tmux user so maybe this is obvious, but how are the environmental variables transferring from the production machines to where the tests are being ru

I am not a tmux user so maybe this is obvious, but how are the environmental variables transferring from the production machines to where the tests are being run? Or, is this stating that the developer started running tests from the production environment?

xtreak29 9y ago
My guess is the second one where the developer assumed that it's a testing environment tmux session but started the test script in a production environment.
oneweekwonder 9y ago
> but how are the environmental variables transferring from the production machines to where the tests are being run? tmux[1] is a terminal multiplexer, a screen alternative. Some speculation, they might have stared the session on a remote machine; set `DATABASE_URL`; use it for something; detach from the session; to later reattached with the bash env still in tack; without the developer being aware he executed the tests commands. Another tmux "problem" is developers using it to tail logs with a infinite back-scroll to only fill up server memory. One solution was to kill all tmux session nightly via cron. Might have helped here. Finally as tui lover, try tmux! Really keeps the frustration at bay if you ssh to a box and your session drop to know your terminal workspace is still in tack. - https://github.com/tmux/tmux/wiki https://github.com/tmux/tmux/wiki
idunno246 9y ago
the tmux thing is a red herring, i encounter similar environment variable things plenty just with open terminal windows(though, not for database_url). i read it as a couple days ago in their local terminal they exported the prod db as an environment variable. ran some script or console or something that needed to run in prod. didnt unset the variable. Then next time they run any command in that terminal it hits prod. maybe it was a remote machine, but there wasnt an active db connection, just a hidden config that exploded the next time a command ran

xtreak29 9y ago

My guess is the second one where the developer assumed that it's a testing environment tmux session but started the test script in a production environment.

oneweekwonder 9y ago

> but how are the environmental variables transferring from the production machines to where the tests are being run? tmux[1] is a terminal multiplexer, a screen alternative. Some speculation, they might have stared the session on a remote machine; set `DATABASE_URL`; use it for something; detach from the session; to later reattached with the bash env still in tack; without the developer being aware he executed the tests commands. Another tmux "problem" is developers using it to tail logs with a infinite back-scroll to only fill up server memory. One solution was to kill all tmux session nightly via cron. Might have helped here. Finally as tui lover, try tmux! Really keeps the frustration at bay if you ssh to a box and your session drop to know your terminal workspace is still in tack. - https://github.com/tmux/tmux/wiki https://github.com/tmux/tmux/wiki

idunno246 9y ago

the tmux thing is a red herring, i encounter similar environment variable things plenty just with open terminal windows(though, not for database_url). i read it as a couple days ago in their local terminal they exported the prod db as an environment variable. ran some script or console or something that needed to run in prod. didnt unset the variable. Then next time they run any command in that terminal it hits prod. maybe it was a remote machine, but there wasnt an active db connection, just a hidden config that exploded the next time a command ran