improve bw/entrypoint.sh behaviour #868
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Remove infinite restart-loop with incorrect condition; make container exit with rc 1 if main nginx exits uncleanly.
I'm not 100% sure whether this leads to the desired behaviour yet (should be tested).
Before: if the
nginx
process crashes,wait $pid
stops blocking, but the crashed proces doesn't cleanup thepid
file so thewhile
loop does nothing and causes 100% load.After: if the main
nginx
proces exits without cleaning up the pid file, it is considered an unclean/unexpected exit and causes the stale pid file to be cleaned up by the entrypoint and the container exiting with status 1.However: if the container orchestrator is configured to restart containers on failure, this would cause a new
bw
instance to be started, so far so good. BUT: will this newly started container request the needed configs from the scheduler upon startup? Or is configuring "push only" (scheduler -> bw)? In the latter case we still have a problem.