¿Por qué cron requiere MTA para iniciar sesión? ¿Hay alguna ventaja particular en esto? ¿Por qué no puede crear un archivo de registro como la mayoría de las otras utilidades?
networking
cron
logs
email
Nikhil
fuente
fuente
Respuestas:
Tenga en cuenta que la forma tradicional "estándar" de registrar datos es syslog , donde los metadatos incluidos en los mensajes son el "código de instalación" y el nivel de prioridad. El código de instalación se puede usar para separar las secuencias de registro de diferentes servicios para que puedan dividirse en diferentes archivos de registro, etc. (aunque los códigos de instalación son algo limitados en el sentido de que tienen significados tradicionales fijos).
Lo que no tiene syslog es una forma de separar mensajes para o de diferentes usuarios, y eso es algo que
cron
necesita en un sistema multiusuario tradicional. No sirve de nada recopilar los mensajes de los trabajos cron de todos los usuarios en un archivo de registro común donde solo el administrador del sistema puede verlos. Por otro lado, el correo electrónico naturalmente permite enviar mensajes a diferentes usuarios, por lo que es una opción lógica aquí. La alternativa sería que cron hiciera el trabajo manualmente y creara archivos de registro en el directorio de inicio de cada usuario, pero se supondría que un sistema Unix multiusuario tradicional tiene un MTA que funciona, por lo que implementarlo en cron habría sido principalmente un ejercicio inútilEn los sistemas modernos, puede haber opciones alternativas, por supuesto.
fuente
Supongo que por "iniciar sesión" te refieres a almacenar la salida real de los trabajos. La ejecución de trabajos ya está registrada en el inicio de sesión cron
/var/cron/log
(la ruta puede diferir entre sistemas). No se requiere MTA para este registro.Un trabajo cron se ejecuta como el usuario de cuyo crontab forma parte el trabajo.
En el caso general, no hay garantía de que este usuario pueda crear archivos en el sistema (un usuario puede no ser un usuario interactivo), especialmente no bajo la
/var
jerarquía donde generalmente se crean registros. Por lo tanto, la forma más segura de notificar al usuario los errores y otros resultados de un trabajo es recopilarlos y enviarlos por correo electrónico al usuario. Esto también permitiría al usuario configurar la redirección de correo electrónico para que la cuenta pueda ver, por ejemplo, errores en su ubicación preferida.Si el usuario desea guardar la salida de un trabajo en un archivo, puede hacerlo con una simple redirección en el crontab:
Esto se ejecutaría
"$HOME/scripts/myscript"
cada dos horas, en la hora, y guardaría todos los resultados"$HOME/logs/myscript.log"
. No se crearán correos electrónicos al ejecutar este trabajo ya que toda la salida se redirige. Sin el2>&1
, los mensajes de error aún se enviarían por correo electrónico.Esto permite al usuario elegir a dónde va la salida.
fuente