Come trovare un fuggitivo Crontab

Qualche anno fa ho impostato un processo cron per eseguire automaticamente il ping di un URL ogni minuto come parte di un sistema di monitoraggio (è una semplificazione eccessiva, ma lo farà per questa domanda). Perché sono una persona orribile, non l'ho documentato da nessuna parte.

Oggi, anni dopo, ho iniziato a riscontrare problemi con l'applicazione all'altra estremità dell'URL sottoposto a ping. L'ho risolto, ma poi ho capito, non ho idea da dove provenga questo cron job .

C'è un modo per cercare rapidamente o cercare tutti i crontab di un determinato sistema? Ho l'accesso come root, quindi le autorizzazioni non sono un problema. Sono sempre stato un utente di cron, non ho mai esaminato troppo a fondo la sua implementazione, ma i miei istinti * nix dicono che ci deve essere un gruppo di file di testo da qualche parte che contiene tutti i crontab. Semplicemente non so dove sarebbero stati, e se lo scavassi avrei paura di trovarne alcuni, ma non tutti, o di perdere qualche strana sfumatura del sistema

Inoltre, realizzo con l'accesso root che potrei

1. Ottieni un elenco di tutti gli utenti nel sistema
2. su come utente
3. crontab -l
4. Ripeti con tutti gli utenti

ma sto cercando qualcosa di meno manuale (e sto cercando di imparare qualcosa sull'implementazione di cron)

Ci sono solo alcuni posti in cui i crontab possono nascondere:

• /etc/crontab
• /etc/cron.d/*
• /etc/crond.{hourly,daily,weekly,monthly}/*
  questi sono chiamati da /etc/crontab, quindi forse un asterisco su questo
• /var/spool/cron/*(a volte /var/spool/cron/crontabs/*)

Assicurati di controllare atanche, che mantiene i suoi lavori in /var/spool/at/o/var/spool/cron/at*/

Inoltre, invece di

su <user>
crontab -l

Basta fare questo:

crontab -lu <user>

I crontab vivono /etc/crontabe (con molte implementazioni) i suoi componenti in /etc/cron.*/*(tutti modificati da root) e in /var/spool/cron/*(crontab degli utenti).

Se hai problemi a localizzare il lavoro incriminato, un altro approccio è quello di indagarne uno mentre è in corso. Ad esempio, è possibile aggiungere una regola firewall per registrare l'id utente del processo che apre le connessioni example.comsulla porta 80:

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

Se il lavoro utilizza un'applicazione come pingo curl, ombreggia il solito binario da un wrapper che registra le informazioni su ciò che lo sta utilizzando, con uno script come questo in /usr/local/bin:

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

Il modo rapido e sporco:

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

La posizione esatta in cui sono archiviati i crontab può variare da sistema a sistema, ma generalmente si trova /var/spoole ha un punto crontabnel nome.

Si noti inoltre che molti sistemi hanno crontab di sistema (come in /etc/crontab, /etc/cron.d) alcuni dei quali possono chiamare più script come /etc/cron.hourly, .daily...

Sembra un cronjob creato da crontab. Non tutti i crontab hanno uno -uswitch, ma per GNU / Linux è disponibile. Questa è una riga utile per elencare tutti i cronjobs creati da crontab.

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

(Esegui come root.)

Se tutto il resto fallisce, puoi creare un honeypot dall'URL che richiede - ovvero servire un file di grandi dimensioni o qualcosa del genere - e cercare il processo che è in attesa di ricevere i dati, quindi cercare il suo PPID.

Qualsiasi sistema decente dovrebbe spiegare la posizione precisa dei crontab nella manpage (di solito nella FILESsezione vicino alla fine, e anche per altri demoni).

Sul mio sistema, ad esempio, cron(8)contiene quanto segue:

 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

E secondo il consiglio di Tylerl di controllare anche i atlavori mentre ci sei.

Avvicinandosi al contrario: cron tiene un registro di ciò che sta facendo, proprio per evitare questo tipo di problemi in primo luogo. Sul mio sistema, il registro è conservato /var/cron/loge si presenta così:

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

Questa riga mi dice che l'istanza cron con PID 20232 sulla macchina fortresssta eseguendo /home/vucar/lighttpd-watchdogper conto dell'utente vucar. Un sistema ben educato ha un solo cron in esecuzione, quindi sarà semplice.

Questo funziona anche per i atlavori, dato che di solito sono solo passati a cron comunque:

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

Gli snippet provengono da un sistema BSD, ma il concetto generale è molto probabilmente lo stesso ovunque.