Crontab et Email

[jcp]

Bonjour a tous,

Je viens de passer en 7.3, réinstalle complete sur du nouveau matériel. J'ai reinstaller la superbe distrib "crontab manager", mais petit soucis, je recois plein d'email a chaque evenement...

Et comme j'ai 3 jobs qui tourne toutes les 5 mns !!! vous imaginez le nombre d'email 'crontab' en fin de journée sur le compte admin ou en fin de semaine !!

On peut modifier cela ?

Cordialement,

Jean-Christophe

[shwing]

si je ne dis pas de bétisse:
il te faut rajouter ceci : >/dev/null à la fin

Exemlpe:

Code: Tout sélectionner

# run traffic monitoring every 5 minutes
*/5 * * * *     /usr/local/bin/monitorTraff > /dev/null

[jdh]

Oui, on voit le nombre d'emails :

5mn -> 12 par heure (60/5) -> 288 par jour (*24)-> 2016 par semaine (*7), et bien évidemment par 3 jobs soit 6048 mails.

Voilà !

J'ai bon ?




Bon, pour redevenir sérieux, ">dev>nul" est (très) utile. Moi j'ajoute encore par sécurité "2>&1" au cas où la commande enverrait des erreurs.

[jcp]

Oui, on voit le nombre d'emails :

5mn -> 12 par heure (60/5) -> 288 par jour (*24)-> 2016 par semaine (*7), et bien évidemment par 3 jobs soit 6048 mails.

Voilà !

J'ai bon ?

Bon, pour redevenir sérieux, ">dev>nul" est (très) utile. Moi j'ajoute encore par sécurité "2>&1" au cas où la commande enverrait des erreurs.

Je n'ai pas fait le calcul mais cela ne doit pas etre loin...

j'ai mis en fin de ligne le > dev/null et je recois toujours l'email !!

Voici la ligne... (commande a executer dans l'interface crontab manager)

/home/e-smith/files/primary/files/test-courant.sh > /dev/null

une idée ?

Ps: Ca fait quoi le 2>&1 ?

Jean-Christophe

[shwing]

Code: Tout sélectionner

# Set time
*/5 * * * *     /usr/local/bin/timecheck > /dev/null 2>&1


What does “> /dev/null 2>&1″ mean?
Published at June 6, 2006 in GNU/Linux. Tags: No Tags.

I remember being confused for a very long time about the trailing garbage in commands I saw in Unix systems, especially while watching compilers do their work. Nobody I asked could tell me what the funny greater-thans, ampersands and numbers after the commands meant, and search engines never turned up anything but examples of it being used without explanation. In this article I’ll explain those weird commands.

Here’s an example command:

wibble > /dev/null 2>&1

Output redirection

The greater-thans (>) in commands like these redirect the program’s output somewhere. In this case, something is being redirected into /dev/null, and something is being redirected into &1.
Standard in, out, and error

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.

Given that context, you can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).

The short explanation, therefore, is “all output from this command should be shoved into a black hole.” That’s one good way to make a program be really quiet!Technorati Tags:No Tags

pas trouvé en FR.

[unnilennium]

en résumé fini tes commandes cron par

Code: Tout sélectionner

> /dev/null 2>&1

ce qui signifie envoyer les sorties standard dans la corbeille et en faire de même pour les messages d'erreurs.

jPP

[jdh]

Une commande unix (linux) dispose nativement de 3 fichiers "INPUT" (n° 0), "OUTPUT" (n° 1) et "ERR" (n° 2).

Par défaut ces 3 fichiers correspondent à, respectivement, le clavier, l'écran (la session), et à nouveau l'écran.

On peut modifier ces 3 fichiers à l'aide des symboles de redirection :

<file remplace "INPUT" (de la même façon que le symbole | (pipe) pour enchaîner des commandes).
>file envoie "OUTPUT" vers le fichier "file"
2>file envoie "ERR" vers le fichier "file"

et astuce complémentaire 2>&1 fait renvoyer "ERR" vers le "OUTPUT".

(On peut aller plus loin avec 3>, ... mais là cela suffit).


Donc " >/dev/nul 2>&1" suffit à s'assurer, en général, que la commande ne donnera aucun résultat, et, par conséquence, pas de mail par le système cron.

[sibsib]

Hello,

En même temps, une tâche bien écrite ne renvoie rien (ni sur STD, ni sur ERR) quand tout s'est bien passé. Comme çà, on peut recevoir un mail en cas de pépins, c'est pas mal non plus.

Je vais vous décevoir, mais

Code: Tout sélectionner

>/dev/null 2>&1

en général, j'appelle çà la politique de l'autruche

On en a déjà causé dans ce même forum (je sais plus quand...)

A+,
Pascal

[shwing]

Comme çà, on peut recevoir un mail en cas de pépins, c'est pas mal non plus.

Donc tu ne renseigne jamais tes lignes avec >/dev/null 2>&1 à la fin ?

[sibsib]

Hello,

Non, jamais

J'écris un script 'propre' qui ne cause pas tant que tout va bien. Comme çà, que le script détecte une erreur ou qu'une erreur arrive que le script n'a pas géré, et là je reçois un mail et çà m'interpelle.

A+,
Pascal

[arapaho]

Heu les résultats de vos crons, vous les jetez ?!? A vrai dire, j'ai un peu de mal à correctement visualiser cela.
Déjà le 2&>1, c'est spécifique au shell Bash. Oui, c'est (malheureusement) Bash que l'on retrouve sur la majorité de installation GNU/Linux, mais il est nécessaire de le savoir avant de se prendre une bâche par le shell (mais quel mauvais jeu de mot ...)

Ensuite, ne pas recevoir de mail de la part de cron parce qu'il est pénible de gérer les quantités générées, ça peut se comprendre. Mais comme indiqué par sibsib, ce n'est pas non plus la peine de le jeter. Si les scripts font trop de

Code: Tout sélectionner

echo "ok"
echo "la c'est coule man"
echo "LOL c'est pheune"
echo "et la maintenant c'est fini"

c'est qu'il faut sévèrement penser à les revoir.
En attendant, écrire les résultats de la tâche dans un fichier, par exemple, est largement préférable. En Bash, ce serait la forme:

Code: Tout sélectionner

2&>1 > file.truc

ou concaténer:

Code: Tout sélectionner

2&>>1

Il est également aussi possible de le donner à manger à un tar qui ajouterai les résultats à chaque exécution et enverrai un digest hebdomadaire.
Mieux: utiliser les propriétés de syslog.

[arapaho]

Bon, autrement la dyslexie n'est qu'une impression: ça n'existe pas.
Il est évident qu'il faut lire 2>&1 et pas 2&>1 .....

[shwing]

ok, bonne précision apporter ici pour ma culture général, Merci Messieurs !