Mi colega corrió grep | crontab. Después de eso todos los trabajos desaparecieron. Parece que estaba tratando de correr crontab -l.
Entonces, ¿qué pasó después de ejecutar el comando grep | crontab? ¿Alguien puede explicar?
Mi colega corrió grep | crontab. Después de eso todos los trabajos desaparecieron. Parece que estaba tratando de correr crontab -l.
Entonces, ¿qué pasó después de ejecutar el comando grep | crontab? ¿Alguien puede explicar?
Respuestas:
crontabpuede instalar nuevo crontabpara el usuario que invoca (o el usuario mencionado como root) que lee desde STDIN. Esto es lo que sucedió en tu caso.
grepsin ninguna opción generará un mensaje de error en STDERR como de costumbre y está conectando el STDOUT grepa STDIN, crontabque está en blanco, por lo tanto, crontabse habrá ido.
¿Cómo terminó el trabajo? ¿Tecleó Cc o Cd? Si escribió Cd, entonces es equivalente a ejecutar crontab < /dev/nully ha reemplazado el archivo crontab del usuario con uno vacío. Por otro lado, si matas crontabcon Cc, entonces el crontab podría haberse conservado, pero puedes verificarlo fácilmente ejecutando crontab -l.
Todo lo que hace este programa es editar los archivos crontab /var/spool/cron/, por lo que si tiene una copia de seguridad del sistema de archivos, puede restaurar el archivo crontab del usuario desde allí.
No vi que no hubiera ningún argumento para grep, por lo que grep fallará y, de hecho, el archivo crontab siempre quedará impresionado.
crontabrequieren que utilice-como nombre de archivo para leer desde la entrada estándar. Supongo que esto se debe a que demasiadas personas volaron sus crontabs con errores como este.