¿Cómo silencia completamente un cronjob a / dev / null /?


72

En mi Ubuntu-Desktop y en mi servidor Debian, tengo un script que debe ejecutarse cada minuto (un script que llama al minuto-tic de mi juego de navegador en línea espacial ).

El problema es que en los derivados de Debian, cron inicia sesión /var/log/syslogcada vez que se ejecuta. Termino viendo repetido el mensaje en el que se ejecutó una y otra vez /var/log/syslog:

Nov 11 16:50:01 eclabs /USR/SBIN/CRON[31636]: (root) CMD (/usr/bin/w3m -no-cookie http://www.spacetrace.org/secret_script.php > /dev/null 2>&1)

Sé que para suprimir la salida de un programa, puedo redirigirlo a /dev/null, por ejemplo, para ocultar todos los mensajes de error y advertencia de un programa, puedo crear una línea en crontab como este

* * * * *       root    /usr/local/sbin/mycommand.sh > /dev/null

Pero me gustaría ejecutar un cronjob y asegurarme de que todos los resultados o errores generados se canalicen a NULL, por lo que no genera ningún mensaje en syslog y no genera ningún correo electrónico


EDITAR:
hay una solución para redirigir los registros cron en un registro separado como se propone aquí cambiando/etc/syslog.conf

Pero el inconveniente es que TODA la salida de todos los cronjobs se redirige.

¿De alguna manera solo puedo redirigir un único cronjob a un archivo de registro separado? Preferentemente configurable dentro del cron.hourlypropio archivo.


2
También puede simplemente ponerlo MAILTO=""al comienzo del archivo cron. Esto suprimirá todos los correos electrónicos. Y nunca he oído hablar de un demonio cron que envíe la salida del trabajo a syslog (pero supongo que es posible).
Patrick

@Patrick: eso deshabilitará todo, lo que podría estar bien, pero solo ten en cuenta. Vea mi actualización, puede configurar múltiples mAILTO's.
slm

Sí, MAILTO=""ya que la primera línea del crontab evitará cualquier correo electrónico. Además, use la trifecta completa en sus líneas de comando si está suprimiendo todos los resultados. Los 3 tipos son redirigidos por esta cadena: >/dev/null 2>&1 - Por supuesto, puede hacer que el script incluya escrituras periódicas en un registro separado.
SDsolar

Respuestas:


119

Haz la línea esto:

* * * * *       root    /usr/local/sbin/mycommand.sh > /dev/null 2>&1

Esto capturará STDOUT (1) y STDERR (2) y los enviará a /dev/null.

MAILTO

También puede deshabilitar el correo electrónico configurando y luego restableciendo el MAILTO=""que deshabilitará el envío de cualquier correo electrónico.

Ejemplo

MAILTO=""
* * * * *       root    /usr/local/sbin/mycommand.sh > /dev/null 2>&1

MAILTO="admin@somedom.com"
 * * * * *      root    /usr/local/sbin/myothercommand.sh

Mensajes adicionales

Muchas veces recibirá los siguientes tipos de mensajes en /var/log/syslog:

Nov 11 08:17:01 manny CRON[28381]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

Estas son simplemente notificaciones a través de cron de que se ejecutó un directorio de cronjobs. Este mensaje no tiene nada que ver directamente con estos trabajos, sino que proviene cronddirectamente del demonio. Realmente no hay nada que pueda hacer al respecto, y le animo a que no los desactive, ya que es probable que sean la única ventana que tiene a crondtravés de los registros.

Si son muy molestos para usted, siempre puede dirigirlos a un archivo de registro alternativo para sacarlos de su /var/log/syslogarchivo, a través del /etc/syslog.confarchivo de configuración syslog.


@ rubo77 - ¿puedes mostrar un ejemplo? Necesitaría ver qué no funciona con esto. Googlear convierte esto como la respuesta: cyberciti.biz/faq/disable-the-mail-alert-by-crontab-command
SLM

Esto funciona para todas las salidas y correos electrónicos, pero aún genera una línea para cada llamada cron en / var / log / syslog
rubo77

@ rubo77: eso es lo que pensé que podrías haber estado preguntando. No puede detener esos mensajes, son generados por el mismo demonio crond.
slm

@ rubo77 - Soy consciente de los cambios /etc/syslog.conf, difícilmente consideraría esto como una alternativa. Eso solo cambiará el archivo en el que se descargan los registros o puede deshabilitar completamente los mensajes cron por completo. No hay una manera de hacer lo que quieres.
slm

1
@ rubo77: la única forma en que podrás hacer lo que quieras es poner un grep -v ...después de la invocación de crond.
slm

10

tener un script que debe ejecutarse cada minuto. El problema es que cron está iniciando sesión en / var / log / syslog cada vez que se ejecuta. Termino viendo repetido el mensaje que fue ejecutado una y otra vez en / var / log / syslog

Dado que nada de lo que hace parece detener esto, vale la pena preguntarse: ¿ qué es exactamente este script y cuál es exactamente el mensaje que ve en syslog?

Si la sugerencia de slm no funcionó, esto se debe a que algo está iniciando sesión en syslog directamente, ya sea cron, como parece estar implicado en algunos de sus comentarios, o bien el proceso ejecutado por cron. Los mensajes enviados a syslog no provienen de stdin o stderr, por 2>&1&>lo que no ayudarán.

Puede haber una forma de configurar el comportamiento de la aplicación en cuestión, excepto que no sabemos de qué se trata.

Ciertamente, hay una manera de configurar la mayoría de las implementaciones de syslog contemporáneas (hay varias) para filtrar mensajes de manera muy específica. Por ejemplo, si hay una etiqueta única utilizada en el mensaje de registro, puede orientarla. Pero una vez más, dado que no sabemos nada sobre el mensaje en particular, o qué syslogd usa, entonces no hay nada específico que pueda recomendarse.

Mi punto general es que si no desea redirigir / filtrar mensajes porque "esto redirigirá todos los mensajes", puede refinar la técnica de filtrado. El hilo de falla del servidor al que se vinculó solo menciona el filtrado por la facilidad ( *.cron), pero puede configurar filtros más especializados que eso.


Debian y Ubuntu tienen rsyslog disponible. En debian 5+ es el syslog predeterminado, en ubuntu es una opción, por lo que deberá instalarlo. Para crear un filtro que se dirija a algún tipo de contenido específico, colóquelo cerca de la parte superior (es decir, antes de cualquier otra regla, pero después de la configuración general, la carga del módulo, etc.) de /etc/rsyslog.conf. La mejor manera de hacer esto no es editarlo en rsyslog.confsí mismo, sino crear un archivo en el /etc/rsyslog.conf.d/directorio, cuyo nombre comience con dos dígitos que tengan menos de 50, es decir /etc/rsyslog.conf.d/15-my-filter.conf. Puedes poner algo como esto:

:msg, contains, "/usr/bin/w3m -no-cookie" /dev/null

Esto enviará el mensaje a /dev/null(o un registro separado si lo prefiere). Sin embargo, el mensaje aún se pasará a través de las reglas posteriores que lo envían /var/log/syslog. Para evitar eso:

& stop

Inmediatamente después de esa otra línea. Esto arroja todo lo que coincida con la regla anterior. O, para las reglas de una sola línea, simplemente puede agregar stopal final de esa línea de regla.

Debe reiniciar rsyslogddespués de cambiar la configuración (por ejemplo, en sistemas systemd systemctl restart rsyslog):

kill -HUP $(cat /var/run/rsyslogd.pid)

HUP hace que el demonio se reinicie.


Para rsyslog ~ahora está en desuso y debe reemplazarse por stop. También rsyslogd.confimporta la posición en el archivo. Entonces, para rsyslog, simplemente usaría :msg, contains, "/usr/bin/w3m -no-cookie" stop. Y luego reiniciar sudo systemctl restart rsyslog.
Frank Breitling

4

Cambio /etc/default/cron

# Or, to log standard messages, plus jobs with exit status != 0:
# EXTRA_OPTS='-L 5'
#
# For quick reference, the currently available log levels are:
#   0   no logging (errors are logged regardless)
#   1   log start of jobs
#   2   log end of jobs
#   4   log jobs with exit status != 0
#   8   log the process identifier of child process (in all logs)
#
EXTRA_OPTS="-L 0"

Por defecto la EXTRA_OPTSlínea es""


2

Redireccionando para /dev/nullocultar la salida del comando. Si no haces esto, cron te envía la salida por correo. El resultado del comando nunca termina en los registros del sistema (al menos no por cron).

Por lo general, es una mala idea redirigir la salida /dev/null, especialmente la salida de error: si algo sale mal, no tendrá información para diagnosticar el problema. Si no desea recibir un correo, redirija a un archivo de registro.

Sin embargo, nada de esto es relevante para su problema. El mensaje que cita es del propio cron. Cron escribe una entrada de registro cada vez que ejecuta un trabajo. Ninguna implementación cron que he visto le permite usar diferentes configuraciones de registro para diferentes trabajos.

Si desea omitir algunos trabajos, su única opción es aplicar el filtrado de texto a los mensajes de registro en el demonio syslog. El estándar de facto para el filtrado de syslog es ejecutar rsyslog (que puede ser o no el predeterminado en su sistema) como el demonio syslog. Vea la respuesta de goldilocks para saber cómo filtrar este comando en particular.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.