PM2 под root сломал деплой на 502

Проект Borisov AI — это сайт с фронтенд-приложением и Strapi API. Всё работало, пока я не начал менять логику запуска процессов в CI/CD. Ветка fix/ci-pm2-selective-delete должна была переместить управление PM2 с root-овского сервера на gitlab-runner, но получилось нечто неожиданное.

Утром проверяю https://borisovai.tech — оба сервиса отдают 502 Bad Gateway. Reverse proxy (Traefik) жив и здоров, но PM2-процессы на портах 4001 и 4002 не отвечают. Заглядываю в PM2 Web UI на сервере — видно, что запущен только scadacoating, а frontend и strapi вообще отсутствуют в списке.

Команда pm2 list под gitlab-runner показывает, что процессы были попытаны запустить, но упали с ошибками. Frontend кричит “Failed to start server”, Strapi жалуется, что порт 4002 уже занят. Вот оно что.

Углубляюсь дальше. Проверяю, что слушает порты 4001 и 4002 — и нахожу два PM2 daemon’а: один под root (запущен давно), второй под gitlab-runner. Root-овый PM2 ещё держит старые процессы frontend и strapi. Когда CI деплоит под gitlab-runner, новые процессы не могут захватить порты — они заняты.

Оказывается, раньше всё запускалось под root, и никто это не трогал. Когда я добавил задачу в CI переместить на gitlab-runner, произошла коллизия: старые процессы продолжали висеть, новые не могли стартовать, и сайт упал.

Решение простое, но требует аккуратности. Останавливаю frontend и strapi в root PM2, меняю права на директорию /var/www/borisovai-site на gitlab-runner, перезапускаю процессы. На этот раз они поднялись чистенько — 0 рестартов, порты свободны, сайт дышит.

Главный вывод: когда меняешь пользователя, под которым запускается сервис, нужно убедиться, что старый процесс полностью мёртв. Иначе порты останутся заняты и новый деплой будет биться в стену. PM2 отлично работает, пока не сталкиваются два инстанса daemon’а с одинаковыми приложениями.

Насчёт Docker — как первая любовь: никогда не забудешь, но возвращаться не стоит 😄