Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Write os-var replaced .src file to temp file, and rename #938

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

chsukivra
Copy link

The replace_os_vars function is called every time for any command, not only those that boot the release. If you call <release> status in a readiness check, that will re-write the file.

This might lead to race conditions, where the release starts up, the script creates the replace_os_vars function, is slowed down, but the health check is invoked and it will re-render the sys.config and write it halfway while the starting release gets around to read that very file.

We do see intermittent examples of this, where one container out of a bunch on a slow machine start up, and a container that has no changes from previous successful runs will fail with and error like this, with same sys.config.src files, same env.

could not start kernel pid (application_controller) (error in config file \"/tmp/sys.config\" (none): no ending <dot> found)

However this container has a healthcheck implemented with the status command running in it.

    healthcheck:
      test: [ "CMD", "/opt/forms/bin/forms", "status" ]

There are many ways to attack this issue. Just opening with a suggestion.

The replace_os_vars function is called for any command, not only those that boot the release. If you invoke <release> status in a readiness check, that will write the file again.

This might lead to race conditions, where the release starts up, but the health check will re-render the sys.config and write it halfway while the boot gets around to read it.
@tsloughter
Copy link
Member

Neat edge case. My only concern is whats the availability of mktemp?

@chsukivra
Copy link
Author

I've also been thinking about introducing an environment variable like RELX_EXPAND_SRC=false that completely disable this generator unless explicitly asked for. If not set or set to true it will keep current behavior.

#!/bin/sh
/opt/myapp/bin/myapp expand_src
exec /opt/myapp/bin/myapp foreground

Its just that it doesnt do the right thing out of the box and that could be annoying.

Also, maybe i can make a bigger change that chose to only generate these files for the commands that will actually start the service? I dont see why status should lead to it being expanded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants