Bonjour,
Le 13/07/2010 14:26, Olivier Desportes a écrit :
> Bonjour
>
> Je ne sais pas si il y a encore grand monde à lire la ML, mais je
> tente le coup :
Pourquoi penses-tu que personne ne lit la ML ?
> J'ai migré des services de debian à redhat EL 5.3. Depuis, j'ai un
> script php qui tourne toutes les 10 minutes qui génère une
> segmentation fault. Que dans cron !
> En plus de ça, alors que les sorties de la tache sont orientés vers
> /dev/null, je reçois quand même un mail qui m'informe de la seg fault.
Le programme qui plante, appelons-le "/bin/toto" doit être appelé comme
ceci :
/bin/toto > /dev/null
dans ce cas, la "sortie standard" (stdout), c'est à dire que ce renvoi
par défaut un "printf", est effectivement jeté à la benne.
Cependant, les programmes UNIX possèdent un autre mode de
communication, appelée "sortie d'erreur (stderr), qui est généralement
destiné à afficher des messages cruciaux, comme par exemple des erreurs.
Cette sortie standard n'est pas affectée par le "> /dev/null".
Par contre, tu peux la re-diriger à la poubelle avec le "2> /dev/null".
> Et puisque l'on est dans la quatrième dimension on continue,
Pas de 4ème dimension, car tu ne redirige pas la sortie d'erreur. Donc
cette-ci fini par échouer dans le mail envoyé par cron.
Exemple de combinaisons :
/bin/toto > /dev/null 2> /tmp/ERREUR.txt
le stderr est redirigé dans /tmp/ERREUR.txt
/bin/toto > /dev/null 2> /dev/null
stdout et stderr sont détruit
/bin/toto > /tmp/RESULT_AND_ERREUR.txt 2>&1
stdout et stderr sont redirigés tout les deux dans
/tmp/RESULT_AND_ERREUR.txt
ATTENTION AVEC CETTE SYNTAXE : L'ordre des deux redirections est important !
> puisque
> malgré l'erreur de segmentation, le script s'execute, et
> correctement...
Facile : Le script lancé par le cron contient plusieurs sous-programme,
et seul l'un deux plante
> A l'aide ? Quelqu'un ?
Phase 1 : tu vas créer un script en BASH, qui va lancer ton script php
qui plante (/bin/toto).
Example :
cat /usr/local/bin/test
#!/bin/bash
set -x
set
exec /bin/toto > /tmp/RESULT.txt 2>&1
Phase 2, Tu vas modifier ta configuration de cron (/etc/crontab ou
/etc/cron*), pour lancer /usr/local/bin/test, et pour que stdout et
stderr soient redirigés vers un fichier. Exemple :
x x * * * root /usr/local/bin/test
ici, "x x" définissent quand le script est exécuté.
Dans "/tmp/RESULT.txt", tu verras plusieurs choses :
- les commandes exécutées par le script /usr/local/bin/test, (ligne "set
-x") et les variables d'environnement d'exécution de cron (ligne "set").
Tu noteras que c'est très différent de ton environnement de root (tape
"set" en temps que root).
Cette différence de variables d'environnement et souvent la source du
problème qui fait qu'un script s'exécute bien en temps que user, mais
pas en temps que "cron".
A toi alors de trouver quelles sont les variables d'environnement qui
posent problème.
> Merci !!
De rien.
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
