RELX_REPLACE_OS_VARS is problematic if disk fills up

[sargun]

If the disk fills up, the new file can get truncated, or be totally empty. It would be nice (and I can do the work if we have a plan), if the script wrote out the new vm.args, or sys config to a tmp directory, of somewhere we could specify. Opinions?

[lrascao]

Sounds good, i've already got a branch with some tests that exercise the replace os vars funcionality, i'll merge that asap so they can be run against your PR.
Out of curiosity, is this an issue that comes up often in your live environment? (running out of disk space and not being able to start the release)

[sargun]

@lrascao We deploy software that's packaged up as part of a bigger package. It often runs alongside other services, and we see all sorts of bad things happen.

It's happened a few times recently, and fixing it is a major pain. (manually restoration, etc..).

[GoelDeepak]

I did some testing in our environment. However, running extra tests would always be helpful. Let me know once you merge your changes.

We are seeing the issue of disk running out of space in our environment. Further, if for some reason the new vm.args (sys.config) is not properly generated then thereon the application keeps failing until somebody manually current that error.

[lrascao]

So i'm writing the tests and i'm getting weird behaviour from this feature, since you guys use it on an actual production environment i'd like your comment on the following to check wether these are bugs or intended behaviour:

• have a sys.config with a var to be replaced ([{goal_app,[{var1,"${VAR1}"}]}].)
• run RELX_REPLACE_OS_VARS=1 VAR1=v1 bin/foo start
• sys.config gets processed and ends up [{goal_app,[{var1,"v1"}]}]. as expected
• sys.config.orig is created but has the same content as sys.config: [{goal_app,[{var1,"v1"}]}].
• stop the node
• start it again, this time RELX_REPLACE_OS_VARS=1 VAR1=v2 bin/foo start
• no variables get replaced this time

this definitely looks like a bug, is this faulty behaviour something you're relying on?

[lrascao]

ping @erlanger

[erlanger]

@lrascao, the second time it is ran it should replace the variable. Looks like a bug to me.

[lrascao]

thanks, i've tracked it down in the meantime

[erlanger]

Great!

[lrascao]

@GoelDeepak @sargun #527 fixes the issues i've mentioned earlier and contains two new tests that exercise this functionality, could you please give it a look and check that it works in your environment?
If everything looks good i'll merge it to master and then you can rebase #526 onto master