Run script in background inside the container from host

NOTE: docker_version:1.13.0 image: ubuntu:14.04

I am trying to run a script in a container that starts a service inside the container. I run this script from an application which is running in the host machine and this application runs multiple scripts inside the container. All other scripts my application is running inside the container, executes successfully. However the script(start_service.sh) which starts the service inside a container executes without any error but does not start the service. But if I go inside the container and run the script as below it successfully starts the service.

docker exec -it TEST /bin/bash
root@TEST# /scripts/start_service.sh

This start_service.sh script does a lot of modification and contains a line at the end which actually starts the service and does not work when start_service.sh is running from my application(in Host machine).

The line inside start_service.sh which actually starts the service is
/opt/$SERVICE.sh > /dev/null 2>&1 &

However if I change this line to
/opt//$SERVICE.sh
my application(in Host machine) starts the service but hangs in there until the service is closed. But obviously the intention is to keep the service running inside the container. It would be possible to use ‘screen’ to run the service in different screen but docker container does not support ‘screen’.

Is there any way I can run this script(start_service.sh) from my host machine that actually starts the service inside the container and does not hang there?

Please feel free to ask any question if the problem explanation is not understandable.

Are you looking for docker run -d?

If you use that, you won’t need to worry about it hanging or backgrounding it yourself (using &) – the container process will run in “detached” mode.

Thank you for the answer. Unfortunately I do not want to start the container in detach mode. I needed to run only the following in detach mode-

/opt/$SERVICE.sh

I don’t understand. You want to run /opt/$SERVICE.sh in the background, that is what --detach is for. If you have multiple scripts to background, run multiple containers.

“docker run -d” will create the whole container in detach mode. Isn’t it?

On that case I think all the other scripts that actually creates the environment for the service will also run in detach mode(Please correct me if I am wrong about this). It takes around 5 minutes for several scripts to prepare the environment for the service. If all the scripts run in detach mode what will happen is, all the scripts will run immediately one by one. On that case “start_service.sh” will run before other scripts prepared the environment for the service.

As the code for running a script (either attach/detach mode) in my application is same for all scripts, I think I should do some modification in that particular script(start_service.sh) which will start only the service(or only ‘start_service.sh’) in detach mode.

What are these scripts for preparing the environment doing that cannot be done ahead of time in docker build?

I think I should have mention it before, I am using a docker api client to communicate with docker daemon. I do not use any Dockerfile to build image or docker cli client to communicate with daemon. What my application does for a particular service-

  1. pulls a general image(ex- ubuntu:16.04)
  2. Runs scripts inside the container that install required packages, setup PATH and relevant modification.
  3. After doing all this. It runs the ‘start_service.sh’ whose main purpose is to run the ‘/opt/$SERVICE.sh’.

I am not sure how to explain this as I do not have good knowledge about this terms. If I run ‘/opt/$SERVICE.sh’ instead of “/opt/$SERVICE.sh > /dev/null 2>&1 &” from inside the container it starts the service and continue to show logs until I press “CTRL +Z” to close the service. Hope this may give you some hint about the service pattern.

I am using a docker api client to communicate with docker daemon. I do not use any Dockerfile to build image or docker cli client to communicate with daemon.

Install the packages, configuration, etc., in a docker build. The tool won’t be nearly as useful if you don’t use it as it’s intended.