My suggestion is to create a third script (runner.sh) and it would be the only command that runs.
Your attempt to use multiple arguments is prone to errors. If it works great, but that command is mixing multiple things together:
- (1) Backgrounding a process,
(2) Redirection of output (stderr to stdout)
(3) Verifying one command worked before running the other,
(4) Running a 2nd command.
I would not try to figure out how docker CMD works to do this but instead use a bash script that does the work. This approach gives you the ability to attach to the container and debug it by running the command if there was any error.
Lastly, when I’m troubleshooting I put the command
sleep 900 to sleep for 15 minutes which gives me time to
docker exec bash into the container to debug it (for up to 15 minutes) before the execution of the container terminates.
./script1.sh > myscript.log 2>&1 &
if [ "$status" -eq "0" ]
# Sleep when debugging the script, comment out after it is working
These are my “best practices”. Take them or leave them.
Some pointers on the scripting for your example,
(1) When you run a command in the background using ampersand (&), the status was always zero so I don’t think it is doing what you were wanting to do. I don’t have a suggestion right now and don’t want to spend the time to look up the answer/approach.
(2) When running commands, you should use the syntax
./your-script.sh and add
#/bin/sh (as I did, so all of your scripts should start with that string). Your commands will fail to start if they are not executable and “on the $PATH”. Using
./your-script.sh makes it work regardless of how your path is set.
(3) I (as my personal best practice) always use double quotes around my parameters in an if statement, this is not technically necessary, but over the years I’ve found it helps when I’m dealing with strings that might be blank (a syntax error occurs otherwise), and it doesn’t hurt to use them “all the time”.