Дыбр из рабочих будней (мы все продолжаем трудиться из дома). Пользователь жалится с утра, что наполучал тонны тревожных писем от watchdog-а, который не смог поднять сервис на одном из его хостов. Первое, что сделали в качестве реакции - зашли на ту машину, и ... увидели сервис радостно дрыгающий ножками и вопрошающий "чего изволите-с?". На всякий случай сервис перезапустили и он бодро побежал дальше. После этого (точно как в юмореске раннего Задонова) пользователь опять шлёт слёзный мейл - на меня сыплются сообщения про упавший сервис! На этот раз за дело взялся ВПС. Первым делом попросил переслать в виде аттачмента образец получаемого мейла (вдруг какой оптический обман здрения?). Проверил заголовок SMTP - действительно прислано с "проблемного" хоста. На всякий случай подергал за сервис еще раз - перезапустил и убедился в его работоспособности. Всё зашибись, но мейлы-то идут! Подключил коллегу (по телефону), стали смотреть вместе. Зашли в лог watchdog-а - действительно ошибки обнаруживаются с завидной периодичностью. Поубивали на всякий случай процессы watchdog-а (которых оказалось два, но мы не обратили внимания). Через какое-то время процессы поднялись по crontab и ошибки понеслись дальше. Повертели файлы конфигурации - ничего криминального, всё как доктор прописал. И тут Соколиный Глаз (в лице моего коллеги) заметил, что второй watchdog бежит не с правами root-а! Это был совсем "левый" процесс, цель которого ограничивалась удалением старых директорий на общем сетевом диске!!! И (естественно) ему нехватало прав не то чтобы запустить сервис, а даже на проверку его состояния.
Вы спросите, а где же мораль и кто виноват? Мораль в том, что crontab этого процесса мы тупо не видели (ибо cron работает строго для каждого пользователя индивидуально). И только посмотрев на то, под каким пользователем бежит злосчастный процесс, можно было догадаться, что он занимается ерундой и шлёт никому не нужные репорты.
Сказка - ложь, да в ней намёк, не забывайте про права процессов, и про crontab других аккаунтов.
Как вариант - использовать из-под cron-а sudo и не лохматить бабушку.
В следующей серии - как дебагировать упавшие сокеты RPyC без дебаггера.
Вы спросите, а где же мораль и кто виноват? Мораль в том, что crontab этого процесса мы тупо не видели (ибо cron работает строго для каждого пользователя индивидуально). И только посмотрев на то, под каким пользователем бежит злосчастный процесс, можно было догадаться, что он занимается ерундой и шлёт никому не нужные репорты.
Сказка - ложь, да в ней намёк, не забывайте про права процессов, и про crontab других аккаунтов.
Как вариант - использовать из-под cron-а sudo и не лохматить бабушку.
В следующей серии - как дебагировать упавшие сокеты RPyC без дебаггера.
Tags: