Як знайти втікача Crontab

Кілька років тому я налаштував завдання Cron для автоматичного запису URL-адреси щохвилини як частини системи моніторингу (це спрощено, але це буде зроблено для цього питання). Оскільки я жахлива людина, я ніде цього не документував.

Сьогодні, через роки, у мене виникли проблеми з додатком на іншому кінці URL-адреси, що надписується. Я це виправив, але потім зрозумів, що я не маю уявлення, звідки береться ця робота з крон .

Чи є спосіб швидкого пошуку або вилучення всіх кронтових даних у певній системі? У мене є кореневий доступ, тому дозволи не є проблемою. Я тільки коли-небудь був користувачем cron, я ніколи не надто глибоко дивився на його реалізацію, але мої інстинкти * нікс говорять, що десь повинна бути група текстових файлів, що містять усі літери. Я просто не знаю, де вони будуть, і якби я заглибився в нього, я б боявся їх знайти, але не всіх, або пропустив би якийсь дивний нюанс системи

Також я розумію, що з кореневим доступом я міг би

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.*/*(усі відредаговані коренем) та в /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

Точне місце, де зберігаються кронтаби , може відрізнятись від системи до системи, але воно, як правило, /var/spoolє і є crontabдесь у назві.

Також зауважте, що у багатьох системах є системні кронти (наприклад, у /etc/crontab, /etc/cron.d), деякі з яких можуть викликати більше сценаріїв, наприклад /etc/cron.hourly, .daily...

Це звучить як cronjob, який був створений crontab. Не у всіх crontabs є -uкомутатор, але для GNU / Linux він доступний. Це зручний рядок, щоб перелічити всі роботи, створені crontab.

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

(Запустити як корінь.)

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

Будь-яка гідна система повинна пояснювати точне розташування кронтових карт на манпажі (як правило, в FILESрозділі, що знаходиться в кінці, а також для інших dæmons).

Наприклад, у моїй системі 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

І я друге поради Tylerl також перевірити, чи немає 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. У добре налаштованій системі працює лише один крон, тому це буде просто.

Це також працює для atробочих місць, так як вони, як правило, просто передаються в cron:

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

Фрагменти походять із системи BSD, але загальна концепція, швидше за все, однакова скрізь.