Bonjour,
Lorsque crontab execute un certain script, il m'envoit le contenu de la sorti dans un email envoyé au compte root... Et le probleme c'est que celui ci est parfois très plein du coup... Alors je me demandais comment faire pour qu'il se taise un peu...
Bref si quelqu'un a une idée :).
Lorsque crontab execute un certain script, il m'envoit le contenu de la sorti dans un email envoyé au compte root... Et le probleme c'est que celui ci est parfois très plein du coup... Alors je me demandais comment faire pour qu'il se taise un peu...
Bref si quelqu'un a une idée :).
> Lire le message (4 commentaires, moyenne: 2,3).
Vous avez demandé le commentaire #715158.
Run by 
Cette page a été générée par Templeet en 0.0455s (dont 0.0044 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
modifier les sorties
J'ai trouvé ça :
http://linuxfr.org/tips/108.html
[^]Re: modifier les sorties
Merci, je vais regarder ca et je vous tiens au courant si ca marche pas.
[^]Re: modifier les sorties
Bonjour,
Je voudrais simplement faire quelques petites remarques à ce sujet.
Effectivement, la sortie standard et la sortie d'erreur d'un programme exécuté par cron sont envoyées par mail à l'utilisateur sous lequel s'exécute le programme. Dans ton cas, il s'agit de root, mais cela fonctionnerait de la même façon pour un autre utilisateur.
Je pensais que le plus souvent, le mail de root n'arrivait pas directement sur le compte root mais était rerouté vers un autre utilisateur (cf fichier /erc/alliases). Visiblement ce n'est pas le cas sur toutes les distributions.
Pour éviter le mail, il faut soit avoir un programme qui ne génère pas de sortie, soit rediriger ces sorties (vers un fichier ou vers /dev/null).
Ces sorties peuvent avoir un intérêt pour détecter un problème à l'exécution. C'est pour cela qu'en général j'évite de tout rediriger vers /dev/null. Dans la mesure du possible, mes programmes en cron n'écrivent rien sur la sortie standard. Si cela n'est pas possible, je redirige cette sortie vers /dev/null ou un fichier en fonction de l'intérêt qu'elle peut avoir. En revanche, je touche rarement à la sortie d'erreur : si le programme écrit sur la sortie d'erreur, c'est qu'il y a eu un problème et dans ce cas il est intéressant de voir ce qu'il s'est passé pour le corriger, et recevoir cette erreur par mail est un moyen pas plus mauvais qu'un autre pour repérer un problème.
Bon, je ne sais pas si ces réflexions vous aideront vraiment, mais prenez-les simplement pour ce qu'elles sont : le résultat de mon expérience (je me sens vieux ce matin ;-( )
A+
JJD