On slow systems, systems with high load or a congested internet connection, Chef may trigger the deployment scripts to run again while a previous instance is still running. This can lead to a corrupted database if a second instance stops or restarts containers while the first instance's initdb processes are still running.
We must implement a locking mechanism which avoids stopping or restarting containers if another script is already running.
On slow systems, systems with high load or a congested internet connection, Chef may trigger the deployment scripts to run again while a previous instance is still running. This can lead to a corrupted database if a second instance stops or restarts containers while the first instance's initdb processes are still running.
We must implement a locking mechanism which avoids stopping or restarting containers if another script is already running.