Как найти беглеца Crontab

Несколько лет назад я настроил задание cron на автоматическое пингование URL-адреса каждую минуту как часть системы мониторинга (это упрощение, но оно подойдет для этого вопроса). Поскольку я ужасный человек, я нигде не документировал это.

Сегодня, спустя годы, у меня начались проблемы с приложением на другом конце URL-адреса. Я исправил это, но потом понял, что понятия не имею, откуда взялась эта работа cron .

Есть ли способ быстро найти или отследить все crontabs в конкретной системе? У меня есть root-доступ, поэтому разрешения не являются проблемой. Я только когда-либо был пользователем cron, я никогда не смотрел слишком глубоко на его реализацию, но мои инстинкты * nix говорят, что где-то должна быть группа текстовых файлов, которые содержат все crontabs. Я просто не знаю, где они будут, и если я вникну в это, то боюсь найти некоторые, но не все, или упустить какой-то странный нюанс системы.

Кроме того, я понимаю, что с правами root я мог

1. Получить список всех пользователей в системе
2. su как пользователь
3. crontab -l
4. Повторите со всеми пользователями

но я ищу что-то немного менее ручное (и хочу узнать что-то о реализации cron)

Кронтабы могут спрятать только в нескольких местах:

• /etc/crontab
• /etc/cron.d/*
• /etc/crond.{hourly,daily,weekly,monthly}/*
  они называются /etc/crontab, так что, возможно, звездочка на этом
• /var/spool/cron/*(иногда /var/spool/cron/crontabs/*)

Обязательно проверьте atтакже, которая сохраняет свою работу в /var/spool/at/или/var/spool/cron/at*/

Кроме того, вместо

su <user>
crontab -l

Просто сделай это:

crontab -lu <user>

Crontabs живут в /etc/crontabи (со многими реализациями) его компонентах /etc/cron.*/*(все отредактированы пользователем root) и в /var/spool/cron/*(пользовательские crontabs).

Если у вас возникли проблемы с поиском оскорбительной работы, другой подход заключается в том, чтобы исследовать ее во время ее работы. Например, вы можете добавить правило брандмауэра для регистрации идентификатора пользователя процесса, открывающего соединения example.comна порт 80:

iptables -A OUTPUT -p tcp --syn -d example.com --dport 80 -j LOG --log-prefix "[->example.com] " --log-uid

Если задание использует приложение, такое как pingили curl, создайте тень на обычный двоичный файл с помощью оболочки, которая записывает информацию о том, что его использует, с помощью сценария, подобного следующему /usr/local/bin:

#!/bin/sh
{
  date
  echo "$0" "$@"
  ps -p $PPID
  echo
} >>"/tmp/$(basename "$0").log"
exec "/usr/bin/$(basename "$0")" "$@"

Быстрый и грязный способ:

grep -r ping /var/spool/cron/crontabs

Точное местоположение, где хранятся crontabs , может варьироваться от системы к системе, но обычно оно /var/spoolнаходится crontabгде-то в названии.

Также обратите внимание , что многие системы имеют системы crontabs (например , в /etc/crontab, /etc/cron.d) , некоторые из которых можно назвать несколько сценариев , как /etc/cron.hourly, .daily...

Это звучит как cronjob, созданный crontab. Не у всех crontabs есть -uпереключатель, но для GNU / Linux он доступен. Это удобная строка для перечисления всех cronjobs, созданных crontab.

for user in $(awk -F':' '{ print $1}' /etc/passwd); do crontab -u $user -l; done

(Запуск от имени пользователя root.)

Если ничего не помогает, вы можете создать приманку из URL-адреса, который он запрашивает - то есть обработать большой файл или что-то в этом роде - и найти процесс, ожидающий получения данных, а затем найти его PPID.

Любая приличная система должна объяснять точное местоположение crontabs на man-странице (обычно в FILESразделе ближе к концу, а также для других демонов).

Например, cron(8)в моей системе содержится следующее:

 FILES
      /etc/crontab          system crontab file
      /var/cron/atjobs      directory containing at(1) jobs
      /var/cron/log         cron's log file
      /var/cron/tabs        directory containing individual crontab files
      /var/cron/tabs/.sock  used by crontab(1) to tell cron to check for
                            crontab changes immediately

И я второй совет Тайлерла, чтобы также проверить atработу, пока ты там.

Подходя к этому наоборот: cron ведет журнал того, что он делает, именно для того, чтобы в первую очередь избежать подобных проблем. В моей системе журнал хранится /var/cron/logи выглядит так:

==> /var/cron/log <==
Oct 25 00:21:01 fortress cron[20232]: (vucar) CMD (/home/vucar/lighttpd-watchdog)

Эта строка говорит мне, что экземпляр cron с PID 20232 на машине fortressвыполняется /home/vucar/lighttpd-watchdogот имени пользователя vucar. Хорошо функционирующая система имеет только один запущенный cron, так что это будет просто.

Это также работает для atрабочих мест, так как они все равно обычно передаются cron:

==> /var/cron/log <==
Oct 25 00:28:01 fortress cron[31282]: (vucar) ATJOB (1414189680.c)

Фрагменты взяты из системы BSD, но общая концепция, скорее всего, везде одинакова.