Docker Run Script для захвата сигнала прерывания

Question

У меня есть docker-compose.yml, который запускает несколько контейнеров. Один из них использует файл Dockerimage для установки всего необходимого в этом контейнере.

Я хотел бы добавить скрипт, который запускается каждый раз, ожидая сигналов прерывания 0, 9 и 137.

Теперь я пытаюсь запустить скрипт как точку входа в файле Dockerimage, но, похоже, не работает.

Это содержимое файла Dockerimage:

RUN apt-get update && [...]
WORKDIR "/application"
ENTRYPOINT ["/bin/bash", "-c", "/application/scripts/cl.sh"] 

Я что-то не так делаю? Нужно ли перестраивать контейнеры с помощью следующей команды?

docker-compose build

---

Это содержимое скрипта bash cl.sh

#!/bin/bash

echo "HELLO HELLO HELLO HELLO"

trap 'echo "Exiting with a 137 signal."' 137 0 9

Единственная цель скрипта на данный момент - тестирование всей работы.

Answer 1

Да, можно достичь того, чего вы хотите, но перед тем, как представить соответствующий код, я должен прокомментировать код вашего вопроса, который содержал некоторые проблемы:

• Неверная строка trap 'echo "Exiting with a 137 signal."' 137 0 9, потому что 137 не является допустимым номером сигнала (см., Например, статью Википедии о сигналах ).

  Возможно, вы только что столкнулись с 137, поскольку это код выхода , соответствующий сигналу 9 (учитывая, что 137 = 128 + 9, см. это приложение в документации bash . )

• 0 (EXIT) и 9 (KILL) являются действительными номерами сигналов, но на практике лучше ловить только 2 (INT) и 15 (TERM), как предложено в этого ответа SE / Unix .

  Действительно, хотя сигналы INT и TERM можно использовать для «постепенного завершения», сигнал KILL означает, что процесс должен быть немедленно завершен и, как указано в man trap:

  Установка ловушки для SIGKILL или SIGSTOP дает неопределенные результаты . […] Перехват SIGKILL или SIGSTOP синтаксически принимается некоторыми историческими реализациями, но не имеет никакого эффекта. Портативные приложения POSIX не могут пытаться перехватить эти сигналы.

• Установка ловушки в конце сценария точки входа - плохая стратегия, поскольку в этом месте она бесполезна. Вместо этого я предлагаю вам определить функцию очистки (последней инструкцией которой является exit), затем установить ловушку для этой функции в начале скрипта и впоследствии запустить свое (не завершающее) приложение.

Отсюда и следующее доказательство концепции:

Dockerfile

FROM debian:latest
WORKDIR /app

COPY entrypoint.bash ./
ENTRYPOINT ["/bin/bash", "./entrypoint.bash"]

entrypoint.bash

#!/bin/bash

cleanup() {
    echo "Cleaning up..."
    exit
}

trap cleanup INT TERM

while :; do
    echo "Hello! ${SECONDS} secs elapsed..."
    sleep 1s
done

Чтобы проверить это, вам нужно просто запустить:

$ docker build -t test-trap .
$ docker run -d --name=TEST-TRAP test-trap
  # wait a few seconds
$ docker stop TEST-TRAP
$ docker logs -f TEST-TRAP
Hello! 0 secs elapsed...
Hello! 1 secs elapsed...
Hello! 2 secs elapsed...
Hello! 3 secs elapsed...
Cleaning up...