🧠 Задача для продвинутых Linux-админов: "Сломанный сервис, который живет вне systemd"
📌 Условие:
У вас есть продакшн‑сервер (Debian/Ubuntu), на котором внезапно начала "умирать" часть бэкенда. Логи в /var/log ничего не показывают, systemctl уверяет, что все сервисы активны. Но один внутренний микросервис processord исчезает каждые 5–10 минут и появляется снова. Пользователи жалуются на случайные 502.
🔎 Что известно:
• В ps aux вы иногда видите processord, а иногда нет
• В journalctl — тишина
• В systemctl list-units — такого юнита нет
• При netstat -tulpen видно, что processord слушает порт 9090, но ненадолго
• Cron выглядит чисто (`crontab -l`, `/etc/cron.*`)
• sshd_config, .bashrc, .profile не тронуты
• /etc/init.d/, /etc/rc.local не содержат вызовов processord
• В /tmp появляется временный скрипт с нечитаемым именем
🧩 Вопросы:
1. Где может прятаться запуск processord, если systemd его не знает?
2. Как отследить, кто запускает процесс?
3. Почему процесс "исчезает" и кто его убивает?
4. Как бы вы автоматизировали его отслеживание без полной остановки сервера?
✅ Разбор и подход к решению:
Шаг 1: Кто его запускает?
Возможные подозреваемые:
- atd — отложенные задачи (проверь `atq`)
- watch, while true, tmux, screen, nohup, disown
- systemd --user (запуск в user-сессии, а не через root)
- ~/.config/systemd/user/ или ~/.config/autostart/
- Unit мог быть удалён, но процесс остался под другим shell'ом
📌 Используй:
auditctl -a exit,always -F arch=b64 -S execve
ausearch -x /usr/bin/processord
inotifywait -mr /tmp /etc /home -e create,open,exec
Шаг 2: Кто его убивает?
Варианты:
OOM-killer (dmesg | grep -i 'killed process')
Сторонняя логика (скрипт мониторинга или autorestart в user‑cron)
ulimit, timeout, или trap внутри родительского скрипта
Нечестный cronjob: проверь /etc/cron.d/, run-parts, anacron и т.д.
📌 Используй:
strace -ff -p $(pidof processord) -o trace.log
или
ps -o ppid= -p $(pidof processord) | xargs pstree -s
Шаг 3: Автоматизация расследования
• Поставь auditd, логируй все execve вызовы
• Используй systemtap или bpftrace для live-трассировки
• Пример:
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s %s\n", comm, str(args->argv[0])); }'
💡 Бонус:
Спроси себя — что если процесс стартует... внутри контейнера или chroot? Или через сторонний бинарник типа supervisord, установленный в /opt?
🧩 Вывод:
Это задача не просто про systemd, а про целостное понимание всей экосистемы процессов в Linux. Уверен, вы найдёте processord. Но вот как вы его найдёте — и покажет ваш уровень.