Jak znaleźć zbiegły Crontab

Kilka lat temu skonfigurowałem zadanie cron, aby co minutę automatycznie pingowało adres URL jako część systemu monitorowania (to nadmierne uproszczenie, ale zrobi to w przypadku tego pytania). Ponieważ jestem okropną osobą, nigdzie tego nie udokumentowałem.

Dzisiaj, lata później, zacząłem mieć problemy z aplikacją na drugim końcu pingowanego adresu URL. Naprawiłem to, ale potem zdałem sobie sprawę, że nie mam pojęcia, skąd pochodzi ta praca crona .

Czy istnieje sposób na szybkie przeszukanie lub wyszukanie wszystkich plików crontabs w danym systemie? Mam dostęp do konta root, więc uprawnienia nie stanowią problemu. Byłem tylko użytkownikiem cron, nigdy nie patrzyłem zbyt głęboko na jego implementację, ale moje instynkty * nix mówią, że musi istnieć gdzieś grupa plików tekstowych, które zawierają wszystkie crontabs. Po prostu nie wiem, gdzie byliby, a gdybym się w to zagłębił, bałbym się znaleźć niektóre, ale nie wszystkie, lub pominąć jakiś dziwny niuans systemu

Ponadto zdaję sobie sprawę z dostępu roota, że ​​mogłem

1. Uzyskaj listę wszystkich użytkowników w systemie
2. su jako użytkownik
3. crontab -l
4. Powtórz ze wszystkimi użytkownikami

ale szukam czegoś nieco mniej manualnego (i chcę dowiedzieć się czegoś o implementacji crona)

Jest tylko kilka miejsc, w których chowają się crontabs:

• /etc/crontab
• /etc/cron.d/*
• /etc/crond.{hourly,daily,weekly,monthly}/*
  są one wywoływane z /etc/crontab, więc może to oznaczać gwiazdkę
• /var/spool/cron/*(czasami /var/spool/cron/crontabs/*)

Pamiętaj również o sprawdzeniu at, który utrzymuje swoje zadania w /var/spool/at/lub/var/spool/cron/at*/

Również zamiast

su <user>
crontab -l

Po prostu zrób to:

crontab -lu <user>

Crontabs żyją /etc/crontabi (z wieloma implementacjami) jego komponenty w /etc/cron.*/*(wszystkie edytowane przez root) i w /var/spool/cron/*(crontab użytkowników).

Jeśli masz problemy ze zlokalizowaniem przestępczego zadania, innym podejściem jest zbadanie jednego w trakcie jego trwania. Na przykład można dodać regułę zapory, aby rejestrować identyfikator użytkownika procesu otwierającego połączenia example.comna porcie 80:

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

Jeśli zadanie korzysta z aplikacji takiej jak pinglub curl, ukryj zwykły plik binarny przez opakowanie, które rejestruje informacje o tym, co z niego korzysta, za pomocą skryptu takiego jak ten w /usr/local/bin:

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

Szybki i brudny sposób:

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

Dokładna lokalizacja, w której przechowywane są pliki crontab, może różnić się w zależności od systemu, ale zazwyczaj /var/spoolznajduje się crontabw nazwie i ma ją gdzieś.

Należy również pamiętać, że wiele systemów mają systemowych crontaby (jak w /etc/crontab, /etc/cron.d), z których niektóre mogą wymagać więcej jak skrypty /etc/cron.hourly, .daily...

To brzmi jak cronjob stworzony przez crontab. Nie wszystkie crontaby mają -uprzełącznik, ale dla GNU / Linux jest dostępny. Jest to przydatna linia do wyświetlenia wszystkich cronjobs utworzonych przez crontab.

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

(Uruchom jako root.)

Jeśli wszystko inne zawiedzie, możesz utworzyć plaster miodu z żądanego adresu URL - tzn. Podać duży plik lub coś - i poszukać procesu, który czeka na otrzymanie danych, a następnie sprawdzić jego identyfikator PPID.

Każdy porządny system powinien wyjaśniać dokładną lokalizację crontabs na stronie podręcznika (zwykle w FILESsekcji pod koniec, a także dla innych demonów).

Na przykład w moim systemie cron(8)zawiera następujące elementy:

 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

Po drugie, radzę tylerlowi, by sprawdzał również oferty atpracy, gdy jesteś przy nim.

Podejście do tego odwrotnie: cron prowadzi dziennik tego, co robi, właśnie po to, aby uniknąć tego rodzaju problemów. W moim systemie dziennik jest przechowywany /var/cron/logi wygląda następująco:

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

Ta linia mówi mi, że instancja crona z PID 20232 na komputerze fortresswykonuje się /home/vucar/lighttpd-watchdogw imieniu użytkownika vucar. Dobrze zachowujący się system ma działający tylko jeden cron, więc będzie to proste.

Działa to również w przypadku atzleceń, ponieważ i tak zwykle są one po prostu przekazywane do crona:

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

Fragmenty pochodzą z systemu BSD, ale ogólna koncepcja jest prawdopodobnie taka sama wszędzie indziej.