Meu colega correu grep | crontab. Depois disso, todos os trabalhos desapareceram. Parece que ele estava tentando fugir crontab -l.
Então, o que aconteceu depois de executar o comando grep | crontab? Alguém pode explicar?
Meu colega correu grep | crontab. Depois disso, todos os trabalhos desapareceram. Parece que ele estava tentando fugir crontab -l.
Então, o que aconteceu depois de executar o comando grep | crontab? Alguém pode explicar?
Respostas:
crontabpode instalar novo crontabpara o usuário que está chamando (ou o usuário mencionado como root) lendo do STDIN. Foi isso que aconteceu no seu caso.
grepsem nenhuma opção gerará uma mensagem de erro no STDERR, como de costume, e você está canalizando o STDOUT greppara o STDIN, o crontabqual está em branco, portanto, você crontabdesapareceu.
Como ele terminou o trabalho? Ele digitou Cc ou Cd? Se ele digitou Cd, é equivalente à execução crontab < /dev/nulle você substituiu o arquivo crontab do usuário por um vazio. Por outro lado, se você mata crontabcom Cc, o crontab pode ter sido preservado, mas você pode verificar isso facilmente executando crontab -l.
Tudo o que este programa faz é editar os arquivos crontab /var/spool/cron/, portanto, se você tiver um backup do sistema de arquivos, poderá restaurar o arquivo crontab do usuário a partir daí.
Não vi que não houvesse argumento para o grep; portanto, o grep irá cometer um erro e, de fato, o arquivo crontab será sempre deslumbrado.
crontabexigem que você use-como o nome do arquivo para ler da entrada padrão. Suponho que isso ocorre porque muitas pessoas explodiram seus crontabs com erros como este.