It is the same, docker will monitor the process you choose as entrypoint. You can use whatever you want., I have a setup to launch and monitor 3 or 4 process in the same container. This is not limited
This is my entrypoint script for manage more than 1 process:
#!/bin/bash
# COMMAND 1
command1 &
status=$?
echo "command1 status" $status
if [ $status -ne 0 ]; then
echo "Failed to start command1: $status"
exit $status
fi
# COMMAND 2
command2 &
status=$?
echo "command2 status" $status
if [ $status -ne 0 ]; then
echo "Failed to command2: $status"
exit $status
fi
# COMMAND 3
command3 &
status=$?
echo "command3 status" $status
if [ $status -ne 0 ]; then
echo "Failed to start command3: $status"
exit $status
fi
# LOOP
while true; do
ps aux |grep command1 |grep -q -v grep
PROCESS_1_STATUS=$?
ps aux |grep command2 |grep -q -v grep
PROCESS_2_STATUS=$?
ps aux |grep command3 |grep -q -v grep
PROCESS_3_STATUS=$?
# If the greps above find anything, they will exit with 0 status
# If they are not both 0, then something is wrong
if [ $PROCESS_1_STATUS -ne 0 -o $PROCESS_2_STATUS -ne 0 -o $PROCESS_3_STATUS -ne 0 ]; then
echo "One of the processes has already exited."
exit 1
else
echo "All processes still running"
fi
sleep 60
done
Yes, and no. This is totally normal. (A bunch of normal prepackaged things like nginx and Apache and database servers and multi-threaded or multi-process.)
Yes. If you docker exec into the container and it has the right tools installed, you can run ps and see the forked process.
The one important caveat (which again you will see with ps) is that the main container process runs as process ID 1 within the container, which gives it some extra responsibility. If you fork(), and your child process fork()s and then exits, the container’s main process will wind up as the parent of the grandchild process. If you then waitpid() you might see process IDs from those descendant processes that you never saw as return values from fork().
IMHO the one compelling reason to run an init process in your container is to take care of this for you. (“My main container process is in a scripting language and depends on shelling out to tools that aren’t good at cleaning up after themselves.”) I’ve seen tini used in the past for this; docker run has an --init option (which runs tini under the hood) but you need to remember to include it on every docker run invocation; it’s probably better to make sure to include an init in your image’s Dockerfile.