Comment désactiver complètement un cronjob dans / dev / null /?

Faites la ligne comme ceci:

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

Cela capturera à la fois STDOUT (1) et STDERR (2) et les enverra à /dev/null .

MAILTO

Vous pouvez également désactiver le courrier électronique en définissant puis en réinitialisant le MAILTO="" qui désactivera l'envoi de tout e-mail.

Exemple

 MAILTO="" * * * * * root /usr/local/sbin/mycommand.sh > /dev/null 2>&1 MAILTO="[email protected]" * * * * * root /usr/local/sbin/myothercommand.sh 

Messagerie supplémentaire

Souvent, vous obtenez les types de messages suivants dans /var/log/syslog :

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

Ce sont simplement des notifications via cron qu'un directory de cronjobs a été exécuté. Ce message n'a rien à voir directement avec ces tâches, il vient directement du démon crond . Il n'y a vraiment rien que vous puissiez faire à ce sujet, et je vous encourage à ne pas les désactiver, car ils sont probablement la seule window que vous avez sur les events de crond via les journaux.

S'ils vous ennuient, vous pouvez toujours les diriger vers un autre file journal pour les extraire de votre file /var/log/syslog , via le file de configuration /etc/syslog.conf pour syslog .

avoir un script qui doit être exécuté chaque minute. Le problème est que cron se connecte à / var / log / syslog chaque fois qu'il s'exécute. Je finis par voir répété le message qu'il a été exécuté dans / var / log / syslog

Puisque rien de ce que vous faites ne semble arrêter cela, il vaut la peine de requestr: qu'est-ce que c'est exactement ce script et quel est exactement le message que vous voyez dans syslog?

Si la suggestion de slm ne fonctionne pas, c'est parce que quelque chose se connecte directement à syslog – soit cron, comme cela semble implicite dans certains de vos commentaires, soit le process exécuté par cron. Les messages envoyés à syslog ne proviennent pas de stdin ou stderr, donc 2>&1&> n'aidera pas.

Il pourrait y avoir un moyen de configurer le comportement de l'application en question, sauf que nous ne soaps pas ce que c'est.

Il existe certainement un moyen de configurer la plupart des implémentations syslog contemporaines (il y en a plusieurs) pour filterr les messages très spécifiquement. Par exemple, si une balise unique est utilisée dans le message de journal, vous pouvez la cibler. Mais encore une fois, puisque nous ne soaps rien sur le message particulier, ou quel syslogd vous utilisez, alors rien de spécifique ne peut être recommandé.

Mon point général est que si vous ne souhaitez pas redirect / filterr les messages car «cela va redirect tous les messages», vous pouvez affiner la technique de filtrage. Le thread de panne de server que vous avez lié à juste mentionne le filtrage par facilité ( *.cron ) – mais vous pouvez configurer des filters plus spécialisés que cela.

Debian et Ubuntu ont tous les deux rsyslog disponibles. Sur debian 5+ c'est le syslog par défaut, sur ubuntu c'est une option, donc vous devrez l'installer. Pour créer un filter qui cible une sorte de contenu spécifique, placez-le près du sumt (c'est-à-dire avant toute autre règle, mais après la configuration générale, le chargement du module, etc.) de /etc/rsyslog.conf . La meilleure façon d'y parvenir est de ne pas modifier le rsyslog.conf lui-même, mais de créer un file dans le directory /etc/rsyslog.conf.d/ , avec un nom commençant par deux numbers inférieurs à 50, c'est /etc/rsyslog.conf.d/15-my-filter.conf dire /etc/rsyslog.conf.d/15-my-filter.conf . Vous pouvez mettre quelque chose comme ça:

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

Cela enverra le message à /dev/null (ou un journal séparé si vous préférez). Cependant, le message sera toujours passé à travers les règles suivantes qui l'envoient à /var/log/syslog . Pour éviter cela:

 & stop 

Immédiatement après cette autre ligne. Cela jette tout ce qui correspondait à la règle précédente. Ou, pour les règles à ligne unique, vous pouvez simplement append un stop à la fin de cette ligne de règle.

Vous devez redémarrer rsyslogd après avoir modifié la configuration (par ex. Sur systemd systems systemctl restart rsyslog ):

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

HUP provoque le redémarrage du démon.

Changez /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" 

Par défaut, la ligne EXTRA_OPTS est ""

Rediriger vers /dev/null masque la sortie de la command. Si vous ne le faites pas, alors cron vous envoie la sortie. La sortie de la command ne finit jamais dans les journaux du système (du less pas par l'action de cron).

C'est généralement une mauvaise idée de redirect la sortie vers /dev/null , en particulier la sortie d'erreur: en cas de problème, vous n'aurez aucune information pour diagnostiquer le problème. Si vous ne souhaitez pas recevoir de courrier, redirigez vers un file journal.

Rien de tout cela n'est pertinent pour votre problème cependant. Le message que vous citez provient de cron lui-même. Cron écrit une input de journal chaque fois qu'il exécute un travail. Aucune implémentation cron que j'ai vue vous permet d'utiliser différentes configurations de journalisation pour différents travaux.

Si vous souhaitez supprimer certains travaux, votre seule option consiste à appliquer un filtrage de text aux messages de journalisation dans le démon syslog. Le standard de facto pour le filtrage syslog est d'exécuter rsyslog (qui peut ou non être la valeur par défaut sur votre système) en tant que démon syslog. Voir la réponse de goldilocks pour savoir comment filterr cette command particulière.