Objet messages de cron

par **trixel** » 06 Août 2007 11:40

Salut tlm,

surement une question stupide de ma part, mais est-il possible de changer l'objet des messages envoyés par CRON ?

Merci

par **sibsib** » 06 Août 2007 21:19

Hi,

Oui .... et non !

Si ta tâche qui tourne en cron est bien écrite, alors elle ne renvoie rien sur la sortie standard, et génère un message tout propre.
Si ta tâche est écrite comme cochon, alors elle renvoie tous les message sur la sortie standard, et c'est le process père (en l'occurrence cron) qui, se bouffant pleins de messages qu'il ne sait pas traiter te les renvoie par mail.

Je ne sais pas si mon propos te cause, mais c'est facile à tester :
Tu lances la tâche directement dans une session shell (également appelée 'session putty' :-)

)
Si le message que tu reçois généralement s'affiche à l'écran, alors ta tâche est écrite comme cochon (et tu ne changeras pas -ou très difficilement- le sujet). Si tu reçois un mail (et rien à l'écran) alors ta tâche est bien écrite, et il reste à trouver dans ta tâche comment le mail est généré pour changer le sujet.

A+,
Pascal

par **MasterSleepy** » 07 Août 2007 08:08

Salut,

@trixel:
Est-ce que tu veux changer le sujet lors qu'un script c'est planté, cad "Cron <root@sme.xxx> /bin/script_qui_plante" ???

Si c'est ça, ce n'est pas possible, j'ai fais un strings sur l'exécutable crond et malheureusement c'est codé dans l'exécutable, donc appart recompiler cette exécutable je ne vois pas comment faire.

A+,
MasterSleepy.

par **trixel** » 07 Août 2007 10:46

non je veux que le sujet d'un message de sauvegarde m'envoie par exemble "[Sauvegarde] : Réussie, ou loupée, " , sauvegarde crée en cron qui lance rsync.
Moi j'ai pas de soucis pour capter ce que c mais pour d'autres qui reçoivent les messages, c pas forcément évident.

par **Cool34000** » 07 Août 2007 21:29

Salut,

Sibsib, je ne suis pas daccord avec toi sur le cochon et la propreté...
Je ne parle pas de l'animal, qui lui, porte bien son nom.. Mais plutôt de ton point de vue.

En effet, c'est déja très révélateur en cas de bug dans une cron (cacher un message d'erreur peut aboutir à un bug un peu plus invisible !)
De plus, si tout se passe bien tu ne recois rien !
Enfin, dans le certains cas (comme le sien visiblement) cela peut être pratique pour recevoir en cron le résultat d'un quelconque script...

Perso je m'en sers dans un de mes scripts de backup pour renvoyer un journal quotidien... Un minimum pour une sauvegarde ! Et c'est justement ce que cherche trixel.
Pour moi, ce code bien écrit me renvoi donc le résultat d'affichage des commandes diverses passés (par exemple le bon déroulement de la sauvegarde MySQL et d'un test sur l'intégrité de la base avant de la sauvegarder)
En cas d'erreur dans ce script (ou d'ailleurs un mauvais fonctionnement) je recois dans ma boite mail le résultat et cela peut servir au futur debug !
En cas de réussite, je recois également un mail, normalement formaté comme un rapport de sauvegarde quoi !

J'avais créé une ébauche de script qui sauvegardait les sites webs (bdd+datas) et la liste des users (avec les LAT) dans une ibay dédié pour mon script addons.sh
C'est un script très minimaliste et à adapter impérativement. Tu peux t'en servir d'exemple, le script est téléchargeable ici.

Avant de lancer le script, il faut créer l'ibay de sauvegarde (je me sers des Lazy Admin Tools, donc il faudra aussi ce RPM... De plus avec modindex il y aura des commentaires sur chaque fichier...)
Le script de sauvegarde était stocké dans /home/e-smith/files/users/admin/

Code: Tout sélectionner: # chmod 744 /home/e-smith/files/users/admin/backup.sh # lat-groups -a -c "sauvegarde | Operateurs de sauvegardes | | admin" # lat-ibays -a -c "sauvegardes | Dossier contenant les sauvegardes SME | sauvegarde | wr-admin-rd-group | local-pw | TON_PASSWORD | enabled" # rm -f /home/e-smith/files/ibays/sauvegardes/html/index.html # echo > /etc/cron.d/sauvegarde # echo "# ADDONS.SH - Script de sauvegarde des sites web" >> /etc/cron.d/sauvegarde # echo "0 4 * * * root /home/e-smith/files/users/admin/backup.sh" >> /etc/cron.d/sauvegarde

Je ne sais pas si tu jugera ce script plutot dans les cochons ou plutot dans les propres... Il reflète en tout cas mon seul et unique besoin avec SME car j'effectue toujours mes sauvegardes sur bandes sur mes serveurs Windows (et le stockage de fichier aussi)

par **jibe** » 08 Août 2007 19:21

Salut,

Bien que je sois certain que sibsib soit assez grand pour se défendre seul :wink:

, je vais quand même lui apporter mon soutien en expliquant mon point de vue de développeur.

En effet, une application bien faite ne devrait jamais laisser quoi que ce soit à l'initiative du système sur lequel elle tourne : tous les cas devraient être envisagés et traités. C'est normal : seule l'application sait exactement quoi faire dans quel cas, et peut donc le faire proprement.

Dans le cas qui nous intéresse ici, l'application (le script de sauvegarde) est parfaitement à même de savoir comment la sauvegarde s'est passée, et peut donc envoyer un mail bien explicite, avec un sujet judicieusement choisi.

Si cette application se contente du traitement par défaut, il se passe ce qu'explique sibsib : les messages sont émis sur la sortie standard et là, cron qui est une application bien faite gère les erreurs générées par les tâches qu'il a lancées, mais n'a pas d'autre moyen que renvoyer tels quels les messages.

Il ne s'agit donc aucunement, comme tu le supposes Cool34000, de cacher des messages d'erreur, mais bien au contraire de traiter correctement l'erreur au lieu de se contenter de laisser le système se débrouiller. Et pour ton journal, il serait préférable que tu le traites jusqu'au bout en l'envoyant par mail, ou en l'enregistrant quelque part plutôt que laisser cron reprendre ce que tu envoies sur la sortie standard.

Ne le prends pas mal : je ne fais que me servir de ton exemple pour décrire ce qui devrait à mon avis être fait de manière générale. Il ne s'agit nullement d'une attaque personnelle, mais d'une critique qui se veut explicative et constructive :wink:

Pourquoi envoyer un tas de trucs inutiles (oui, oui, je dis bien : inutilles.) dans des mais ? Dans la plupart des cas, il passeront dans la corbeille sans être lus ! Tu génères un fichier de log propre et bien organisé, où il est possible de retrouver tous les détails de la sauvegarde, et tu te contentes d'envoyer un mail court mais explicite lorsque c'est nécessaire. Et au besoin, tu génères en plus du log très détaillé un rapport résumé enregistré dans un fichier ou une base de données où il sera facile de savoir ce qui a été sauvegardé et quand, au lieu d'avoir à le retrouver dans un lot d'emails mal organisés !

par **Cool34000** » 08 Août 2007 19:34

Salut,

Non je ne me sens pas attaqué :lol:

J'expliquais juste mon point de vue et tu as magnifiquement exposé le tien.

Jibe a écrit:Pourquoi envoyer un tas de trucs inutiles (oui, oui, je dis bien : inutilles.) dans des mais ?

C'est une vieille habitude que j'ai prise : je m'envoi les rapports de sauvegarde de tous mes clients (SME ou pas) et c'est la 1ère chose que je traite le matin. En cas de problème c'est l'appel immédiat du client (après analyse du log de sauvegarde).
J'aurai pu prendre le temps de faire un script "qui parle dans un mail", j'ai préféré la cron qui est finalement très basique mais qui marche comme je l'ai expliqué pour mon besoin... Simple et efficace !

par **sibsib** » 08 Août 2007 21:50

Hello vous deux,

J'adore quand on parle de moi, çà flatte mon égo :-)

Alors en effet, je n'ai pas du être suffisamment clair, et je m'en excuse.

Oui, comme le dit JiBé, un script bien fait ne compte pas sur un autre process pour faire un rapport.
Donc, dans tous mes scripts, je mets tout ce qu'il faut pour générer des mails 'à ma sauce' (en fait j'ai fait ma librairie perso pour çà, notamment, mais également pour gérer des logs qui me vont bien, et gérer autant que faire se peut l'ingérable, en 'trappant' tous les types d'interruptions. Ceci me permet d'avoir des mails à ma sauce, quel que soit l'OS sur lequel tourne mon script -dans mon cas, Linux, Solaris et/ou Windows).

Dans ce contexte, donc, le message a le format que je veut.

Cependant, cool34000, je n'empêche pas cron de m'envoyer un mail si quelque chose se passe mal, bien au contraire ! Au cas ou un problème que je n'ai pas prévu de trapper se produit (je ne produis pas du code bug free malheureusement), je suis bien heureux que cron m'en informe !

Cependant, il me parait inconcevable que le mode de retour 'normal' d'un script soit la sortie d'erreur de cron !

Vouhala,
Pascal

par **jibe** » 09 Août 2007 00:02

sibsib a écrit:Cependant, il me parait inconcevable que le mode de retour 'normal' d'un script soit la sortie d'erreur de cron !

C'est vrai que ça peut être pratique pour un script vite fait à usage de test ou perso. Mais ça reste "une solution cochonne" :wink:

par **Cool34000** » 09 Août 2007 00:29

Salut,

Bon... Hé ben Cool34000 est un cochon #-o

ROLF

M'enfin avec des redirections de sortie et un envoi par mail ca fait quelques commandes en plus et mon pauvre P4 2400MHz sera surchargé de travail (le pauvre, il tourne à 0.07% en permance !) :lol:

Comme je l'ai dit, c'est un script tout simple... Mais c'est présentable :wink:

[->] Je sors parce que les 2, ils vont me jeter des cailloux ! :-ooo:

par **jibe** » 09 Août 2007 09:20

Salut,

Bon, alors disons que c'est du travail d'a... (Mais laissez-moi finir avant de me traiter de raciste :lol:

) ...mateur. Je sais que tu ne le prendras pas mal, puisque tu m'as dit ne pas être développeur et ne pas savoir programmer...

Ca marche relativement bien, mais ça n'a pas la perfection et le fini d'un travail de pro (encore qu'un pro de Redmond et un amateur finlandais auraient tendance à me contredire :lol:

)

Ou encore, comme ce n'est pas mon épouse qui me reprochera mon racisme, je dirais que c'est du boulot de philippin. Ces braves gens ont assez tendance à mettre en application l'adage "ne fais pas aujourd'hui ce qu'un autre peut faire demain à ta place".

Pourquoi en effet s'emm*** à faire maintenant ce que cron fera plus tard ? C'est effectivement un point de vue. Mais ma réponse reste : "parce qu'on n'est jamais si bien servi que par soi-même".

D'ailleurs, si le script de sauvegarde utilisé par trixel traitait lui-même les messages de sauvegardes, ce topic n'aurait pas été créé...

par **Gaston** » 09 Août 2007 14:43

Bonjour,
il est plus simple dans certains cas de savoir exactement ce que l'on veut partager comme informations (partager vec le système dans le cas présent); Pour être efficace la lecture d'un log doit permmetre de localiser et interpréter les errerurs le plus rapidement possible.
Qui a réellement le courage de lire le mail consécutif à un rsync sur un répertoire de plus de 1000 fichier et d'y repérer sans erreur LE fichier qui a posé un problème ?
Utiliser les stdout et stder est une solution facile, rapide et qui marche dans la plupart des cas. Par contre utiliser des fichiers logs, les parser et renvoyer une synthèse de l'opération est une solution qui prendra plus de temps à être mise en place mais facilitera l'exploitation à plus long terme.
Les deux métthodes sont complémentaires, quand on sait pourquoi et comment les utiliser.
Une remarque néanmoins, quid d'un core dump sur un stdout (ben oui j'ai déjà vu ça ...) ... bonjour la tête du mail à retraiter après

G.

Objet messages de cron

Objet messages de cron

Qui est en ligne ?