Какие команды использовать для проверки backend процесса на сервере с root-доступом

Что проверяют

Есть ли у вас порядок диагностики, а не набор случайных команд: жив ли процесс, слушает ли порт, отвечает ли, что в логах, хватает ли ресурсов. Следом обычно спрашивают: «Сервис в статусе active, а запросы не проходят, что дальше?»

Как отвечать

Идите по слоям:

• systemd: systemctl status app покажет состояние, PID, время старта, хвост лога и код выхода; systemctl list-units --failed найдёт упавшие юниты;
• логи: journalctl -u app -f или journalctl -u app --since "10 min ago", для файловых логов tail -f;
• процесс: ps aux, pgrep -a app, top или htop; подробности в /proc/<PID>/: status, limits, открытые дескрипторы в fd;
• сеть: ss -tlnp покажет слушающие порты и их процессы, lsof -i :8080 то же по одному порту;
• ответ приложения: curl -sv http://127.0.0.1:8080/health отделяет проблему приложения от проблемы балансировщика или файрвола;
• ресурсы: df -h и df -i для диска и инодов, free -h, journalctl -k или dmesg -T для следов OOM killer;
• глубже: strace -p <PID> покажет, на каком системном вызове висит процесс.

Если сервис в контейнере, логика та же: docker ps, docker logs, docker inspect или kubectl describe pod и kubectl logs --previous.

Про root скажите отдельно: большую часть можно посмотреть и без него, а привилегии нужны для ss -p по чужим процессам, strace и части логов. Используйте sudo точечно, а не сидите в постоянной root-сессии.

Где спотыкаются

Называют netstat основным инструментом. В современных дистрибутивах пакета net-tools часто нет, стандарт сейчас ss и ip.

Останавливаются на ps: процесс есть, значит всё работает. Процесс может висеть в deadlock, не слушать порт или упираться в лимит дескрипторов.

Сразу делают systemctl restart или kill -9. Симптом исчезает вместе с уликами: сначала снимите логи и состояние, потом перезапускайте.