crontab

La plupart des tâches cron sont exécutées à un moment où elles n’empiètent pas sur les ressources du serveur (i.e. la nuit).

Or crontab envoie un email récapitulatif à chaque fois qu’une tâche est complétée, ce qui peut vite devenir pénible à gérer.

Heureusement, il existe plusieurs manières d’empêcher de recevoir ces emails de notification de tâches cron.

1. Méthode nucléaire : rendre la variable MAILTO nulle

Vous pouvez éditer le fichier /etc/crontab et rendre la variable MAILTO nulle, comme ceci:

MAILTO=""Code language: JavaScript (javascript)

Cela désactive effectivement tous les emails envoyés depuis crond. C’est par contre une méthode nucléaire : si vous voulez une notification, il faudra l’envoyer depuis le script et non cron.

Cela empêche également de recevoir toute notification en cas d’erreur de la tâche cron, ce qui est très gênant – ce n’est pas vraiment la méthode que je conseille.

2. Rediriger STDOUT et STDERR vers null pour supprimer toute sortie

Si vous supprimez la sortie du script, crond n’aura rien à envoyer.

Ajoutez ceci à l’entrée de votre crontab pour envoyer toute sortie (STDERR et STDOUT) vers /dev/null:

>/dev/null 2>&1Code language: JavaScript (javascript)

Voici un exemple qui lance un script toutes les 5 minutes, sans sortie:

*/5 * * * * /example/script >/dev/null 2>&1Code language: JavaScript (javascript)

Le principal inconvénient est que cela supprime également toutes les erreurs qui pourraient être utiles au débuggage du script.

3. Configurer crond pour envoyer la sortie du script vers les logs système et désactiver la notification de la sortie

Vous pouvez configurer crond en éditant le fichier /etc/sysconfig/crond pour y changer la ligne CRONDARGS.

L’argument -s envoie la sortie vers le log système et l’argument -m off désactive la notification email du résultat de la tâche.

Voici un exemple :

cat /etc/sysconfig/crond

Résultat:

# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS=-s -m offCode language: PHP (php)

Il faut ensuite relancer le service cron pour appliquer la nouvelle configuration avec les nouveaux arguments:

service cron restart

Conclusion

Toutes ces méthodes permettent de supprimer totalement les notifications emails du service cron lorsqu’une tâche est lancée.

Si vous souhaitez ne pas produire de sortie mais garder la possibilité de recevoir un email en cas d’erreur, pensez à rediriger STDOUT vers /dev/null:

*/5 * * * * /example/script > /dev/nullCode language: JavaScript (javascript)

Ce matin, j’ai reçu ce message d’erreur de mon serveur par email :

/etc/cron.daily/logrotate:
error: line 672139 too long in state file /var/lib/logrotate/status
error: could not read state file, will not attempt to write into it
run-parts: /etc/cron.daily/logrotate exited with return code 1Code language: JavaScript (javascript)

Sous les systèmes GNU/linux, logrotate est le service qui archive les fichiers log de manière à ne pas travailler sur des fichiers trop lourds.

Les fichiers sont donc archivés plus ou moins régulièrement, selon leur taille et leur utilisation : certains sont archivés tous les jours, d’autres toutes les semaines.

Or, si logrotate ne fonctionne pas correctement, la taille des fichiers explose, ce qui posera tôt ou tard un souci sur le serveur.

Lorsque logrotate n’arrive pas à lire ou à écrire dans le fichier /var/lib/logrotate/status, il faut :

1. supprimer le fichier /var/lib/logrotate/status :

rm -rf /var/lib/logrotate/statusCode language: JavaScript (javascript)

2. et relancer logrotate :

logrotate -f /etc/logrotate.conf

Le fichier /var/lib/logrotate/status ne sert finalement qu’à garder une trace de la dernière rotation des fichiers logs. Ce fichier ne devrait pas contenir énormément de lignes.

Ps : si vous utilisez Varnish, commentez les lignes le concernant dans /etc/logrotate.conf, il est peu utile d’encombrer le serveur avec les logs de ressources statiques.