pm2-runtime внутри docker контейнера получает SIGTERM - почему?

Question

Я использую виртуальную машину с docker, которая реализует нашу инфраструктуру CI / CD.

docker -compose имеет nginx обратный прокси-сервер и другую службу. По сути, команда запуска этого docker контейнера является сценарием оболочки, который создает локальные копии файлов из центрального репозитория. Затем этот сценарий оболочки запускает (с помощью yarn start) сценарий nodejs, который выбирает несколько служб и создает файл запуска приложения pm2 json.

Наконец, с этим запускается pm2-runtime файл определения приложения. Это делается с помощью

const child = exec(`pm2-runtime build/pm2startup.json`)

child.stdout.on("data", data => { process.stdout.write(data); })

child.stderr.on("data", data => { process.stderr.write(data); })

child.on("close", (code,signal) => {
  process.stdout.write((`pm2-runtime process closed with code ${code}, signal ${signal}\n`));
})

child.on("error", error => {
  process.stderr.write((`pm2-runtime process error ${error}\n`));
})

child.on("exit", (code, signal) => {
  process.stdout.write((`pm2-runtime process exited with code ${code}, signal ${signal}\n`));
})

Существует около 10 приложений, управляемых pm2, скажем, docker stats, контейнер потребляет больше 850 МБ памяти. Однако я нигде не ставил никаких явных ограничений памяти. Я также не могу найти ничего неявного.

Время от времени перезапускается контейнер служб. Согласно журналам dockerd его задача завершена. Это правда: процесс pm2-runtime (см. Выше), как сообщается, закрыт из-за SIGTERM.

И это единственное сообщение, которое я получаю по этому поводу. Никаких других сообщений pm2, никаких служебных сообщений, никаких событий docker.

Теперь я ищу совет, как найти причину этого SIGTERM, потому что у меня заканчиваются идеи.

Answer 1

Как выяснилось, это был действительно фрагмент внутри вопроса, который вызвал проблему.

pm2startup.json ссылается на долго работающие приложения. Со временем, в зависимости от использования, они создают довольно много журналов на stdout и / или stderr. В какой-то момент определенный буфер, сохраняемый exec, заполняется, и процесс узла, который запускается pm2-runtime, останавливается. К сожалению, он останавливается без всякого намека на указание причины взлома sh Но это другая история.

Решение в моем случае заключалось в том, чтобы обойтись без exec или execFile, но вместо этого взять spawn с опцией stdio {stdio: "inherited"} (или подробной версией ["inherited", "inherited", "inherited"]).