Il mio collega corse grep | crontab. Successivamente tutti i lavori sono scomparsi. Sembra che stesse cercando di scappare crontab -l.
Quindi cosa è successo dopo aver eseguito il comando grep | crontab? Qualcuno può spiegare?
Il mio collega corse grep | crontab. Successivamente tutti i lavori sono scomparsi. Sembra che stesse cercando di scappare crontab -l.
Quindi cosa è successo dopo aver eseguito il comando grep | crontab? Qualcuno può spiegare?
Risposte:
crontabpuò installarne una nuova crontabper l'utente che invoca (o l'utente citato come root) leggendo da STDIN. Questo è quello che è successo nel tuo caso.
grepsenza alcuna opzione genererà un messaggio di errore su STDERR come al solito e si sta eseguendo il piping dello STDOUT su grepSTDIN di crontabcui è vuoto quindi non crontabci sarà più.
Come ha terminato il lavoro? Ha digitato Cc o Cd? Se ha digitato Cd, allora equivale a correre crontab < /dev/nulle hai sostituito il file crontab dell'utente con uno vuoto. D'altra parte, se uccidi crontabcon Cc, allora il crontab potrebbe essere stato preservato, ma puoi controllarlo facilmente eseguendolo crontab -l.
Tutto ciò che questo programma fa è modificare i file crontab /var/spool/cron/, quindi se hai un backup del file system, puoi semplicemente ripristinare il file crontab dell'utente da lì.
Non ho visto che non c'erano argomenti per il grep, quindi grep sbaglierà e in effetti il file crontab sarà spazzato via sempre.
crontabrichiedono di utilizzare-come nome file per leggere dallo standard input. Presumo che ciò sia dovuto al fatto che troppe persone hanno fatto esplodere i loro crontab con errori come questo.