Un script ne s'exécute pas correctement avec CRON

Support Debian
#1

Salut,

Je reviens à la charge avec, on peut le dire, un problème à la CRON! :stuck_out_tongue:
Le fait est que j’ai fait un script qui me sert à backupper des sites web (data + BDD), qui marche très bien lorsque je l’exécute manuellement, mais qui ne s’exécute pas entièrement avec CRON.

Voici toutes les infos dont vous aurez besoin pour m’aider, car je n’arrive pas à faire avancer le schmilblick.
Ma Crontab:

# crontab -e
# m h  dom mon dow   command
01 * * * * root run-parts /etc/cron.hourly >> /var/log/cron
02 13,19 * * 1-5 root run-parts /etc/cron.daily >> /var/log/cron

Mon /etc/cron.daily:

-rwxr--r--   1 root root 1249 2008-01-31 13:08 dump_site1
-rwxr--r--   1 root root 1333 2008-01-31 13:11 dump_site2
-rwxr--r--   1 root root 1275 2008-01-31 13:09 dump_site3
-rwxr--r--   1 root root 1314 2008-01-31 13:09 dump_site4

[code]# vi /etc/crontab

/etc/crontab: system-wide crontab

Unlike any other crontab you don’t have to run the `crontab’

command to install the new version when you edit this file

and files in /etc/cron.d. These files also have username fields,

that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

m h dom mon dow user command

17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

[/code]

Comme vous le savez, sh est le shell par défaut sous debian, ce qui n’est pas le cas sous Red Hat par exemple où ce sera le bash. Je dis ceci car j’ai importé ces scripts d’un autre serveur (Red Hat) et qu’il fonctionnaient avec un Sha-bang de type #!/bin/bash que j’ai donc transformé en #!/bin/sh pour que cela fonctionne avec cron.
J’ai même été surpris de voir qu’il fallait également que j’enlève mes terminaisons de type dump_site1.sh.

Le fait est qu’actuellement, si j’effectue un

anacron -n -f, tous mes scripts se lancent et font leur travail correctement, comme lorsque je les appelle manuellement avec ./dump_site1.

Bref, ce matin, le cron.daily ne m’a donné que les dumps mysql, et non pas les archives en .tar que j’attendais.

J’ai également vérifié TOUTES mes variables d’environnement des scripts, elles sont toutes dans les chemins cités dans le PATH de /etc/crontab

Pour info, mon script consiste simplement a faire un dump d’une base, prendre le répertoire dans /var/www, faire une archive .tar.gz du tout, le stocker dans un répertoire donné, et renvoyer le tout par rsync sur un autre serveur.
Et je le redis, tout fonctionne correctement en manuel, je ne vois pas mon erreur, qui doit être stupide, j’en conviens!

Si quelqu’un a une idée, merci d’avance! :slightly_smiling:

#2

Si je comprends bien, tu veux dire que seule une partie du script dump_site1 est exécutée ?

#3

Oui, tout à fait, celui-ci effectue le dump de base mysql et visiblement s’interrompt avant de créer l’archive dump_monsite_date.tar.gz, me laissant un fichier .sql tout seul.
Et ceci se produit pour tous les sites (4 dumps)avec les tâches cron.

Mais, comme je l’ai dit, l’erreur ne peut pas venir du script puisque celui-ci s’exécute parfaitement manuellement, ou encore en forcant la crontab avec la commande anacron -n -f, qui me lance l’ensemble des dumps de tous mes sites, sans aucune erreur en sortie.

#4

Salut,

Le problème persiste, les dumps sql s’accumulent sans l’archive complète, et je suis donc obligé de backupper tous les jours manuellement…GRRR.
Très pratique pour les sauvegardes le week end… :unamused:

#5

[quote=“fullmetalucard”]
Mais, comme je l’ai dit, l’erreur ne peut pas venir du script puisque celui-ci s’exécute parfaitement manuellement, ou encore en forcant la crontab avec la commande anacron -n -f, qui me lance l’ensemble des dumps de tous mes sites, sans aucune erreur en sortie.[/quote]

Si le script s’interrompt ou non selon le cas, c’est quand même qu’il y a quelque chose à coriger dans celui-ci.

Je te propose d’inclure dans ce script une ligne qui enregistre les variables d’environnement dans un fichier, du style

set > /tmp/fichier.log

En comparant le contenu de ces fichiers, selon que le script est lancé à la main ou via cron, ça ne m’étonnerait pas que tu trouves des différences, dans la variable $PATH, par ex.

Et poste le code de ce fameux script, il y aura bien un gourou du bash qui interviendra.

Bàt,

G.

#6

Merci à toi,

Je me doutais effectivement que l’erreur tourne au niveau des variables d’environnement appellées par le script.
J’ai placé la ligne que tu m’as donnée dans le scrip et voici la sortie du fichier.log:

BASH=/bin/sh BASH_ARGC=() BASH_ARGV=() BASH_LINENO=([0]="0") BASH_SOURCE=([0]="./dump_sites_web.sh") BASH_VERSINFO=([0]="3" [1]="1" [2]="17" [3]="1" [4]="release" [5]="i486-pc-linux-gnu") BASH_VERSION='3.1.17(1)-release' CURRENTDATE=2008_02_04_11h15 DB_DUMP_FILENAME=dump_NOMDEMONSITE_2008_02_04_11h15.sql DIRSTACK=() DIR_BACKUP=/home/sauvegarde/NOMDUSERVEUR/NOMDEMONSITE DIR_SITE=/var/www EUID=0 GROUPS=() HOME=/home/sauvegarde HOSTNAME=NOMDUSERVEUR HOSTTYPE=i486 IFS=' ' LANG=fr_FR.UTF-8 LOGNAME=root MACHTYPE=i486-pc-linux-gnu MAIL=/var/mail/root OLDPWD=/home/sauvegarde OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PIPESTATUS=([0]="0") POSIXLY_CORRECT=y PPID=15283 PS4='+ ' PWD=/home/sauvegarde/NOMDUSERVEUR/NOMDEMONSITE SHELL=/bin/sh SHELLOPTS=braceexpand:hashall:interactive-comments:posix SHLVL=2 SITE_NAME=NOMDEMONSITE SQL_BASE=NOMDEMABASE SQL_HOST=localhost SQL_PASS=MDPSQL SQL_USER=root SSH_CLIENT='MONIP 1649 22' SSH_CONNECTION='MONIP 1649 1 IPSERVEUR' SSH_TTY=/dev/pts/0 TERM=xterm UID=0 USER=root _='Suppression des fichiers de sauvegarde de plus de 7 jours'

Le env me donne ceci:

TERM=xterm SHELL=/bin/bash SSH_CLIENT=172.28.32.205 1649 22 SSH_TTY=/dev/pts/0 USER=root MAIL=/var/mail/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/home/sauvegarde LANG=fr_FR.UTF-8 PS1=\h:\w\$ SHLVL=1 HOME=/root LOGNAME=root SSH_CONNECTION=MONIP 1649 1 IPSERVEUR 22 _=/usr/bin/env OLDPWD=/tmp

Est-ce bien ces deux éléments q’il faut comparer? Lorsque tu dis “En comparant le contenu de ces fichier” tu parle du fichier log et de mon script?

A tout hasard, voici les variables de mon script:

NOMDEMONSERVEUR:/home/sauvegarde# vi dump_sites_web.sh

#!/bin/sh

############################### Variables ###############################
HOME="/home/sauvegarde"
DIR_BACKUP="$HOME/NOMDEMONSERVEUR/NOMDEMONSITE"
DIR_SITE="/var/www"
SITE_NAME="NOMDEMONSITE"


SQL_USER="root"
SQL_PASS="MDPROOT"
SQL_BASE="NOMDEMABASE"
SQL_HOST="localhost"
#7

Non, tu lances le script à la main ou avec anacron (puisque tu écris que dans ce cas, ça marche) et tu sauvegardes le fichier log.

Puis tu lances le script via cron (puisque là ça ne marche pas) et tu obtiens une seconde version du fichier log.

Tu compares ces deux fichiers:

$ diff fichier.log.1 fichier.log.2

#8

Merci pour tes éléments,

j’ai modifié mon script dans /etc/cron.daily.
J’aurais le retour demain matin, j’effectuerais alors le diff entre les deux fichiers.

#9

Bien,

voici le contenu du diff netre les deux fichiers:

[code]5c5
< BASH_SOURCE=([0]="./dump_sites_web")

BASH_SOURCE=([0]="/etc/cron.daily/dump_sites_web")
8,9c8,9
< CURRENTDATE=2008_02_07_14h36
< DB_DUMP_FILENAME=dump_monsite_2008_02_07_14h36.sql

CURRENTDATE='2008_02_07_ 7h35’
DB_DUMP_FILENAME='dump_monsite_2008_02_07_ 7h35.sql’
23,24c23
< MAIL=/var/mail/root
< OLDPWD=/home

OLDPWD=/
28c27
< PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
31c30
< PPID=19209

PPID=18803
34c33
< SHELL=/bin/bash ==> Pourquoi?

SHELL=/bin/sh
36c35
< SHLVL=2

SHLVL=5
42,45c41
< SSH_CLIENT=‘MON IP 4153 22’
< SSH_CONNECTION=‘MON IP 4153 IP SERVEUR 22’
< SSH_TTY=/dev/pts/0
< TERM=xterm

TERM=dumb
47d42
< USER=root
[/code]

Visiblement le shell n’est pas le même, celui d’etc/cron.daily est le sh et celui lorsque je le lance manuellement est le bash.

Pourtant le script est doté d’un Sha-bang #!/bin/sh dans les deux cas; et ce la marche avec l’environnement bash, comble de l’ironie, et pas l’inverse.
J’avais même essayé de forcer le shell de la crontab en bash (SHELL=/bin/bash) au lieu de SHELL=/bin/sh; cela ne marchait pas.
Les path des variables sont les mêmes, donc l’environnement est le même semble-t’il.
Décidément je ne vois pas comment contourner ce problème, HELP!!

#10

[quote=“gvdm”]
En comparant le contenu de ces fichiers, selon que le script est lancé à la main ou via cron, ça ne m’étonnerait pas que tu trouves des différences, dans la variable $PATH, par ex.

Et poste le code de ce fameux script, il y aura bien un gourou du bash qui interviendra.
Bàt,
G.[/quote]

Voici le script dump_sites_web:

[code]#!/bin/sh

############################### Variables ###############################
HOME="/home/sauvegarde"
DIR_BACKUP="$HOME/nom_serveur/nom_site"
DIR_SITE="/var/www"
SITE_NAME=“nom_site”

SQL_USER=“user"
SQL_PASS=”***************"
SQL_BASE="nom_base"
SQL_HOST=“localhost”

############################## Sauvegarde ###############################
CURRENTDATE=$(date +%Y_%m_%d_%kh%M)

DB_DUMP_FILENAME=“dump_”$SQL_BASE"_"$CURRENTDATE".sql"

echo "Export de la base de données…"
echo “création du fichier $DB_DUMP_FILENAME”

cd $DIR_BACKUP
mysqldump -h $SQL_HOST -u $SQL_USER -p$SQL_PASS $SQL_BASE > $DB_DUMP_FILENAME

echo "création du fichier $DIR_BACKUP/dump_$SITE_NAME.tar.gz"
tar czf dump_$SITE_NAME_$CURRENTDATE.tar.gz $DIR_SITE/$SITE_NAME $DB_DUMP_FILENAME

echo “export terminé…”

echo "suppression du fichier sql créé…"
rm $DIR_BACKUP/$DB_DUMP_FILENAME

############################# Nettoyage #################################
echo “Suppression des fichiers de sauvegarde de plus de 7 jours”
#find $DIR_BACKUP/ -iname *.tar.gz -type f -ctime +7 -print -delete
set > /tmp/fichier.log ==> redirection de l’environnement pour analyse
echo “synchronistion des sauvegarde avec le serveur de production…”
#rsync --rsh=ssh -avztpog /home/ root@adresse_ip:/home/sauvegarde/nom_serveur/nom_site
#rsync --rsh=ssh -avztpog /home/sauvegarde/nom_serveur/nom_site/ root@adresse_ip:/home/sauvegarde/nom_autre_serveur/nom_site

[/code]

Mais pour le gourou, j’attends toujours…!! :wink:

#11

bonjour

j’ai les yeux qui se croisent dans tes variables :laughing: je te propose de le reprendre à tete repose et de le simplifier :wink:

j’ai fait script de se style et qui tourne encore avec une base de rsync qui se lance toute les heures et qui remplace que les fichiers modiifer

a+ gilles

#12

Salut,

Et bien, en gros, si l’on veut faire la trace du bug, on constate que le script échoue après avoir effectué le dump SQL de la BDD. C’est à dire, qu’il plante au moment de créer l’archive.tar.gz.
Donc, deux possibilités:

  • soit la commande tar n’est pas reconnue par l’environnement; ce qui m’étonnerais car les PATH des shells sont identiques.

  • soit les variables SITE_NAME_$CURRENTDATE ne sont pas reconnue pour crééer le tar.gz.

Des idées? Eventuellement pour déclarer des variables inconnues au système…

#13

salut

se script marche, je l’est teste

#!/bin/sh ############################### Variables ############################### DIR_BACKUP="/home/backup" DIR_SITE="/var/www/monsite" SQL_USER="root" SQL_PASS="monpwd" SQL_BASE="mabase" SQL_HOST="localhost" CURRENTDATE=$(date +%Y%m%d%kh%M) ############################## Sauvegarde ############################### DUMP="dump_"$SQL_BASE"_"$CURRENTDATE".sql" echo "Export de la base de données..." echo "création du fichier $DUMP" cd $DIR_BACKUP mysqldump -h $SQL_HOST -u $SQL_USER -p$SQL_PASS $SQL_BASE > $DUMP echo "création du fichier $DIR_BACKUP/dump_$DIR_SITE.tar.gz" tar czf $DIR_BACKUP/$CURRENTDATE.tar.gz $DIR_SITE/ $DUMP echo "export terminé..." echo "suppression du fichier sql créé... $DIR_BACKUP/$DUMP" #rm $DIR_BACKUP/$DB_DUMP_FILENAME ############################# Nettoyage ################################# echo "Suppression des fichiers de sauvegarde de plus de 7 jours" #find $DIR_BACKUP/ -iname *.tar.gz -type f -ctime +7 -print -delete #[b]set > /tmp/fichier.log[/b] ==> redirection de l'environnement pour analyse echo "synchronistion des sauvegarde avec le serveur de production..." #rsync --rsh=ssh -avztpog /home/ root@adresse_ip:/home/sauvegarde/nom_serveur/nom_site #rsync --rsh=ssh -avztpog /home/sauvegarde/nom_serveur/nom_site/ root@adresse_ip:/home/sauvegarde/nom_autre_serveur/nom_site

enle les # que j’ai mis

a+ gilles

#14

Salut,

Tout d’abord, merci de t’intéresser à ma cause. J’ai vu vite fait que tu avais enlevé les variables SITE_NAME ainsi que le DB_DUMP_FILENAME.

Dans tous les cas, je teste cela ce soir, et je te tiens au courant.

#15

[quote=“fullmetalucard”]Code:

crontab -e

m h dom mon dow command

01 * * * * root run-parts /etc/cron.hourly >> /var/log/cron
02 13,19 * * 1-5 root run-parts /etc/cron.daily >> /var/log/cron
[/quote]

Salut,

dans crontab il n’y a pas a donner de compte il me semble pas besoin d’avoir root ci-dessus…
enfin peut être que ça passe surtout que tu dis que le script s’execute au moins à moitier

#16

Salut,

Encore une fois, cela n’a pas vraiment marché,
Le script a effectué le dump, également, et a tenté de créer une archive encore une fois, avec un nom tronqué, du type:

20080209 20080210
avec le dump à côté, qui lui est au bon format(dump_monsite_2008_02_09_ 7h35.sql)
au lieu de

dump_monsite_2008_02_09_7h35.tar.gz
dump_monsite_2008_02_10_7h35.tar.gz

Si je m’amuse à faire la comparaison avec le script initial,
j’avais un résultat du type:

Donc dans les deux cas, c’est réellement au moment de la construction de l’archive, qu’un problème est intervenu. Ce truc va me rendre dingue.

Dieux du SHELL, aidez-moi!! :confused:

#17

Je dirais que la barre en rouge est dans le mauvais sens si c’est un répertoire, mais si tu arrives au bon résultat hors cron…

#18

Mouaip… je doute effectivement que le problème vienne de là…

J’ai refait ma crontab, histoire de, avec:

00 00 * * 1-5 /home/sauvegarde/scripts_backups/dump_site2 00 00 * * 1-5 /home/sauvegarde/scripts_backups/dump_site1 00 00 * * 1-5 /home/sauvegarde/scripts_backups/dump_site3 00 00 * * 1-5 /home/sauvegarde/scripts_backups/dump_site4

Et le résultat est le même, j’obtiens ceci:

dump_site_2008_02_12_ dump_site_2008_02_12_ 0h00.sql

La tâche se lance bien à minuit, crée un dump sql, au bon format, et commence à créer une archive qui bloque sur l’heure ou le format tar.gz. C’est du délire :angry:

#19

salut

je l’est installe, modifier et sa à marché… cree un rep backup dans le home modifi le script comme il doit et relance en manuel
met le script dans /sbin

a+ gilles

#20

Une remarque en passant, j’ai lu juste le début du fil (pas mal de boulot) mais tu as tort de modifier /bin/bash en /bin/sh. /bin/bash est toujours présent sur une debian et /bin/sh désigne un lien vers un shell qui est celui par défaut. Cela est souvent bash mais peut être dash. Cela crée des incompatibilités (j’ai eu beaucoup de soucis à cause de ça). Si ton script est prévu pour bash, remet /bin/bash au début, tu t’éviteras des ennuis.