Мій колега побіг grep | crontab. Після цього всі робочі місця зникли. Схоже, він намагався бігти crontab -l.
Отже, що сталося після запуску команди grep | crontab? Хтось може пояснити?
Мій колега побіг grep | crontab. Після цього всі робочі місця зникли. Схоже, він намагався бігти crontab -l.
Отже, що сталося після запуску команди grep | crontab? Хтось може пояснити?
Відповіді:
crontabможе встановити нове crontabдля користувача, що викликає (або згаданого користувача як root), що читає з STDIN. Це те, що трапилося у вашому випадку.
grepбез будь-якого варіанта буде генеруватися повідомлення про помилку на STDERR, як зазвичай, і ви переносите STDOUT grepна STDIN, з crontabякого порожній, отже, вас crontabне буде.
Як він припинив роботу? Він набрав Cc чи Cd? Якщо він набрав Cd, він еквівалентний запущеному, crontab < /dev/nullі ви замінили файл crontab користувача порожнім. З іншого боку, якщо ви вб'єте crontabз Cc, то він може бути збережений, але ви можете легко перевірити це, запустивши crontab -l.
Все, що ця програма робить - це редагувати файли crontab /var/spool/cron/, тому, якщо у вас є резервна копія файлової системи, ви можете просто відновити файл crontab користувача звідти.
Я не бачив, щоб не було аргументу grep, тому grep вийде з помилки, і дійсно файл crontab буде здуватися завжди.
crontabвимагають використовувати-як ім'я файлу для читання зі стандартного вводу. Я припускаю, що це тому, що занадто багато людей підірвали свої кронатки такими помилками.