Mój kolega uciekł grep | crontab. Następnie wszystkie prace zniknęły. Wygląda na to, że próbował uciec crontab -l.
Co się stało po uruchomieniu polecenia grep | crontab? Czy ktoś może wyjaśnić?
Mój kolega uciekł grep | crontab. Następnie wszystkie prace zniknęły. Wygląda na to, że próbował uciec crontab -l.
Co się stało po uruchomieniu polecenia grep | crontab? Czy ktoś może wyjaśnić?
Odpowiedzi:
crontabmoże zainstalować nowy crontabdla wywołującego użytkownika (lub wspomnianego użytkownika jako root) czytającego ze STDIN. Tak się stało w twoim przypadku.
grepbez żadnej opcji wygeneruje komunikat o błędzie na STDERR, jak zwykle, i przesyłasz STDOUT grepdo STDIN, crontabktórego jest puste, a zatem crontabnie będzie.
Jak zakończył pracę? Czy napisał Cc czy Cd? Jeśli wpisze Cd, jest to równoważne z uruchomieniem, crontab < /dev/nulla plik crontab użytkownika został zastąpiony pustym. Z drugiej strony, jeśli zabijesz za crontabpomocą Cc, to crontab mógł zostać zachowany, ale możesz to łatwo sprawdzić, uruchamiając crontab -l.
Jedyne, co robi ten program, to edycja plików crontab /var/spool/cron/, więc jeśli zdarzy się, że masz kopię zapasową systemu plików, możesz po prostu przywrócić stamtąd plik crontab użytkownika.
Nie widziałem, żeby nie było argumentu dla grep, więc grep się nie powiedzie i plik crontab będzie zawsze usuwany.
crontabwymagają użycia-jako nazwy pliku do odczytu ze standardowego wejścia. Zakładam, że dzieje się tak, ponieważ zbyt wiele osób wysadziło swoje tabele z takimi błędami.