Running a custom script using entrypoint in docker-compose

Question

I modified the docker-compose.yml file as given on https://hub.docker.com/_/solr/ by adding a volumes configuration and a change in entrypoint. The modified file is as given:

version: '3'
services:
  solr:
    image: solr
    ports:
     - "8983:8983"
    volumes:
      - ./solr/init.sh:/init.sh
      - ./solr/data:/opt/solr/server/solr/mycores
    entrypoint:
      - init.sh
      - docker-entrypoint.sh
      - solr-precreate
      - mycore

I need to run this 'init.sh' before entrypoint starts, to prepare my files inside container.

But I get following errors:

ERROR: for solr_solr_1 Cannot start service solr: oci runtime error: container_linux.go:247: starting container process caused "exec: \"init.sh\": executable file not found in $PATH"

Earlier I found about official image hooks in neo4j from here. Is there a similar thing I can use here also?

Update 1: From comments below, I realized that dockerfile set WORKDIR /opt/solr due to which executable file not found in $PATH. So I tested by providing the absolute path to entrypoint by using /init.sh. But this also gives error, but a different one:

standard_init_linux.go:178: exec user process caused "exec format error"

Pompey

shouldn't it be ./init.sh ?? – Roorback

Thanks, that helped a bit. I tried ./init.sh and it gave same error but then I tried /init.sh and that gives permission denied. – Pompey

The dockerfile sets WORKDIR /opt/solr, so I guess it looks for init.sh in that path. – Aunt

permission denied, so you might to make sure that init.sh has +x in the permissions (chmod +x init.sh) – Roorback

I think thats right, WORKDIR may be the reason for path not found. So I tried giving absolute path Update: My fault @Roorback , the /init.sh gives permission denied when the file was not present. I mounted at wrong place. After mounting correctly, I got exec format error. Anyone knows how entrypoint works? – Pompey

@Pompey Permission denied usually means that you are missing the executable flag in the init.sh file. fix that with chmod locally and rebuild the image. – Aunt

Thanks @Aunt That was fixed! I rebuilt the image and I got exec format error – Pompey

Just run docker-compose exec solr bash and try to run the scripts if you still have problems. It's normally a lot easier to troubleshoot inside the container. – Aunt

That is an option, but I am preparing to ship this image and automate the build process and running docker exec will effect just my system. So I want it to be done by docker-compose. – Pompey

Answer 1

It looks like you need to map your volume to /docker-entrypoint-initdb.d/

version: '3'
services:
  solr:
    image: solr
    ports:
     - "8983:8983"
    volumes:
      - ./solr/init.sh:/docker-entrypoint-initdb.d/init.sh
      - ./solr/data:/opt/solr/server/solr/mycores
    entrypoint:
      - docker-entrypoint.sh
      - init

From

https://hub.docker.com/_/solr/

Extending the image The docker-solr image has an extension mechanism. At run time, before starting Solr, the container will execute scripts in the /docker-entrypoint-initdb.d/ directory. You can add your own scripts there either by using mounted volumes or by using a custom Dockerfile. These scripts can for example copy a core directory with pre-loaded data for continuous integration testing, or modify the Solr configuration.

The docker-entrypoint.sh seems to be responsible for running the sh scripts based on the arguments passed to it. So init is the first argument which in turn tries to run init.sh

docker-compose logs solr | head

Update 1:

I had struggled to get this to work and finally figured out why my docker-compose was not working while the docker run -v pointing to the /docker-entrypoint-initdb.d/init.sh was working.

It turns out that removing the entrypoint tree was the solution. Here's my final docker-compose:

version: '3'
services:
  solr:
    image: solr:6.6-alpine
    ports:
     - "8983:8983"
    volumes:
      - ./solr/data/:/opt/solr/server/solr/
      - ./solr/config/init.sh:/docker-entrypoint-initdb.d/init.sh

my ./solr/config/init.sh

#!/bin/bash
echo "running"
touch /opt/solr/server/solr/test.txt;
echo "test" > /opt/solr/server/solr/test.txt;

Summertree

I was able find a workaround by including init.sh in a script which would run outside the container and then start the container. But this seems better! – Pompey

sorry I have just tested this and it looks like its not working – Summertree

I think it should be working after edits. Please check. – Pompey

Answer 2

An alternative solution that worked for me was modifying entrypoint by placing /bin/sh.It looked a bit like this afterwards

version: '3'
services:
  web:
    build: .
    volumes:
    - .:/code
    entrypoint :  
    - /bin/sh
    - ./test.sh
    ports:
    - "5000:5000 

where test.sh is the required bash script to be run inside the container.

Bedfast