Running a bash script outside of docker container as part of the docker-compose process

FatLinux · November 16, 2022, 11:42am

re: Technical Support queries

Hi there,

I have configured my application to automatically startup by creating a docker-compose.yml file in

/var/sota/storage/docker-compose/

So when the module boots up with torizon it starts to run the docker-compose process. Here is my docker-compose.yml file

version: “2.4”
services:

lol:
image: clotspot/lol
# The line below doesn’t work, really need to run this bash shell outside of the container
command: bash -c “source ./BTini.sh”>
privileged: true
# Accept the EULA required to run imx8 vivante graphic drivers
environment:
- ACCEPT_FSL_EULA=1
ports:
- “55555:55555”
device_cgroup_rules:
# … for /dev/dri devices
- ‘c 226:* rmw’
- ‘c 199:* rmw’
# … for USB devices
- ‘b 8:* rmw’
volumes:
- type: bind
source: /tmp
target: /tmp
- type: bind
source: /dev
target: /dev
- type: bind
source: /media
target: /media
bind:
propagation: shared
- type: bind
source: /var/run/dbus
target: /var/run/dbus
- data:/opt/data

volumes:
data:

The problem is that the docker-compose.yml script above does not call the BTini.sh script, and that is needed to connect my bluetooth printer. BTini.sh is a simple script that sets up rfcomm0.

#!/bin/bash*

MAC=“14:B4:57:F4:7C:96”*
echo "power on " | bluetoothctl | grep power*
echo “devices” | bluetoothctl | grep Device*
echo “trust ${MAC}” | bluetoothctl | grep Pairable*
paired() {
echo “info ${MAC}” | bluetoothctl | grep “Paired” | cut -d " " -f 2
}

rfcommIn() {
echo “-sh /dev/rfcom0” | rfcomm | grep rfcomm0 | cut -d “:” -f 1
}

if [ “$(paired)” = “yes” ]; then
echo “Paired”
else
echo “pair ${MAC}” | bluetoothctl | grep Attempting
fi

if [ “$(rfcommIn)” = “rfcomm0” ]; then
echo “rfcomm device bound on ${MAC}”
else
echo "no rfcomm, setting up binding printer ${MAC} "
sudo rfcomm bind rfcomm0 14:B4:57:F4:7C:96
fi

Inside the debian container there is no bluetooth.service, and setting up the rfcomm0 device first up seems to be the simplest way forward.
My app in the container happily prints to the bluetooth device provided BTini.sh is run manually before “docker-compose up” is run manually.
The problem is that torizoncore calls up docker-compose, and I can’t see how to execute BTini.sh before starting the container launch process?

Any ideas how I can achieve automatic container boot up which calls the BTini.sh script before launching the container?

Thank you for you help

Fat Linux

josep.tx · November 16, 2022, 1:10pm

Hello @FatLinux ,
This seems to be a recurrent question, there is even an open issue in Docker:

github.com/docker/compose

Hooks to run scripts on host before starting any containers

opened 10:40AM - 30 May 19 UTC

Jamie-

kind/feature status/0-triage

This is clearly a common problem lots of people have been facing (even since 201…4, #468), there's pile of closed issues for similar functionality to be added before and they have been closed, I believe, entirely un-reasonably. Please see #1341 for a very concise argument as to why this functionality is useful, and judging by the **reactions to most of the comments**, it is quite a popular feature the community would like added. Now it's over 2 years since #1341 was closed I believe hook-like functionality should be reconsidered. ## Is your feature request related to a problem? Please describe. There are many examples in #1341 already but I'll add my most recent use case for this. I have a number of containers that are spun up, using compose, for development which require a shared data directory. I also need to access that directory on my host. Inside each of my containers a Python program is started as a specific user (as to mimic production as accurately as possible). Currently I mount this volume on each of my containers in docker-compose like so: ``` volumes: - "/tmp/data-var:/var/data" ``` However `/tmp/data-var` doesn't exist on my host (this is a shared development project), so it's created by docker for me, as root. Therefore my Python programs, running as non-root, cannot write to it. Before `docker-compose up` starts any containers, I'd like to call something like `mkdir /tmp/data-var && chown +w /tmp/data-var`. Then on `docker-compose down` after all containers are destroyed I'd like to remove the temp data directory `rm -rf /tmp/data-var`. I understand this _could_ be accomplished in other ways, please see the alternatives section below as to why these suck. ## Describe the solution you'd like I'd like to have two bash scripts, say `pre-up.sh` and `post-down.sh` and add them to be called via docker-compose with something like the following in my `docker-compose.yml` ``` version: "3" pre-up: "./pre-up.sh" post-down: "./post-down.sh" services: service1: build: . volumes: - "/tmp/data-var:/var/data" ``` Other possible hooks people might find useful: * `post-up`: Called after containers have all started * `post-stop`: Called after containers have been stopped (either with ^C or docker-compose stop) * `pre-down`: Called before destroying containers and networks (with `docker-compose down`) * etc. When calling these, compose should block at the specified point until the script has returned with an exit code of 0, and itself stop with a non-zero exit code if the script exits with a non-zero code. ## Describe alternatives you've considered There are alternatives for _my example_ use case, and equally good reasons they're a bad fit. ### 1. Calling a script on container start I could have an `ENTRYPOINT ["start.sh"]` which sets the correct permissions on the directory, then my Python run command be specified via `CMD ["python", ...]` and have `start.sh` finally call `exec "$@"`. However this is a waste as the first container to get started, and every container restart after would do the same thing, it only needs to be done once before any containers start. Equally, it wouldn't solve my `post-down: "./post-down.sh"` use case. ### 2. Wrapping it up in a different script I could write a wrapper script that calls `docker-compose up`, as that's been suggested many times in other issues. Come on... we're all using compose because it's concise, neat, tidy and simple to use. Everything is specified in one place which makes it easy for beginners to understand and read what's going on. Compose itself is essentially a standard when using docker with multiple containers. ### 3. Compose events Though my understanding of events is lacking, due to how complex it is for what I really want to do. This is a poor way to achieve the goal I described, just like many other issues that were raised, then all pointed to #1510 (compose events). Events are reactive, this needs to be proactive, but more importantly, **events do not block**, and for many people, like me, blocking is essential.

Digging into the comments of this feature request I found this:

I haven’t tried it but it looks promising
You can try it and let us know the outcome.

Best regards,
Josep

jeremias.tx · November 16, 2022, 8:07pm

As an alternative solution you might be able to do this using systemd services. On TorizonCore there is a service that runs on boot that starts the docker-compose file located at /var/sota/storage/docker-compose/.

This is the service here: meta-toradex-torizon/docker-compose.service at dunfell-5.x.y · toradex/meta-toradex-torizon · GitHub

You could modify or override this service to add the ExecStartPre field as described here: systemd.service

This field will run before the main ExecStart command defined in this service. In this way it may be possible to run your script before your compose file is brought up.

Best Regards,
Jeremias