1

I cannot get a script to return to bash.

The script is kicked off via the following Docker directives:

ENTRYPOINT ["/bin/bash", "-c"]
CMD ["set -e && /config/startup/init.sh"]

The init script looks like this:

#!/bin/bash

if [ -d /etc/postfix/init.d ]; then
    for f in /etc/postfix/init.d/*.sh; do
        [ -f "$f" ] && . "$f"
    done
fi

echo "[x] Starting supervisord ..."
/usr/bin/supervisord -c /etc/supervisord.conf

bash

And this is the command I use to kick off the image into a container:

docker run -it --env-file ENV_LOCAL mailrelay

The init script runs as expected (and I see output from the scripts within the /etc/postfix/init.d/ directory and supervisord kicks off Postfix.

The problem is getting the script to return to the parent process (bash) instead of needing to start a new one. After it hits the supervisord the session sits there, requiring a Ctrl+C to get it to get back into a bash prompt.

If I leave off the call to bash at the end of the init.sh script, Ctrl+D exits the script AND the container, returning me to the host OS (osx). If I replace the bash call with exit, it returns to the host OS as well.

Is supervisord behaving the way it's supposed to, by running in the foreground this way? I'd like to be able to easily get back into the container shell session to check to see if things are running. Am I left with needing to Ctrl+D (into the secondary bash session) in order to do this?

UPDATE Marc B

take out the bash line, so you don't start a new shell. and if supervisord doesn't go into the background automatically, you could try running it with & to force it into the background, or maybe there's an extra cli option to force it to go into daemon mode

I've tried removing the last call to bash, but as I've mentioned it just sits there still, and Ctrl+D takes me to the host OS (exits the container).

I just tried /usr/bin/supervisord -c /etc/supervisord.conf & (and left off the call to bash at the end) and it just immediately returns to host OS, exiting the container. I assume because the container had nothing left to "do", and so stopped.

AVProgrammer
  • 1,344
  • 2
  • 20
  • 40
  • if you want to get back to the parentl shell prompt, why are you firing up a NEW bash at the end of the script? that kicks you into that child bash, not the parent one. – Marc B Apr 21 '16 at 15:13
  • Yes, how do I get back to the parent one? – AVProgrammer Apr 21 '16 at 15:22
  • take out the `bash` line, so you don't start a new shell. and if supervisord doesn't go into the background automatically, you could try running it with `&` to force it into the background, or maybe there's an extra cli option to force it to go into daemon mode – Marc B Apr 21 '16 at 15:26

1 Answers1

2
#!/bin/bash

if [ -d /etc/postfix/init.d ]; then
    for f in /etc/postfix/init.d/*.sh; do
        [ -f "$f" ] && . "$f"
    done
fi

echo "[x] Starting supervisord ..."
/usr/bin/supervisord -c /etc/supervisord.conf
one
bash # You are spawning a new bash shell here. Remove this statement

At the end your're stuck in a child bash shell :(

Now if you're not returning to the parent shell, the last command that you have run is the culprit.

/usr/bin/supervisord -c /etc/supervisord.conf

You can either force the command to run in the background by

/usr/bin/supervisord -c /etc/supervisord.conf & #the & tells to run in background

A workaround for keeping the container open is mentioned here

Community
  • 1
  • 1
sjsam
  • 21,411
  • 5
  • 55
  • 102
  • This seems to work, except that the container exits I presume because the script completes and so bash (PID 1) terminates, which then the Docker daemon stops... – AVProgrammer Apr 21 '16 at 15:41
  • 1
    @AVProgrammer: See [this question](http://stackoverflow.com/questions/28212380/why-docker-container-exits-immediately) – sjsam Apr 21 '16 at 15:51
  • 1
    Thanks @sjsam I've decided to run supervisord as PID 1 and use `/etc/supervisord.conf` (the helpful include directive) to kick off the scripts that init.sh is kicking off (with process specific config). Thank you. – AVProgrammer Apr 21 '16 at 16:02