Script OK manuellement mais pas en crontab
Clikti
-
dmganges Messages postés 150 Date d'inscription Statut Membre Dernière intervention -
dmganges Messages postés 150 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
J'ai un script d'export de base de données et de backup de ces dernières qui fonctionne manuellement. Mais il ne fonctionne pas lorsque je fais une tâche automatisée avec crontab.
Voici le script en question :
#!/bin/bash
#
# Backup des bases de donnees
#
#On récupère le jour, le numéro de semaine, le mois et l'année de la sauvegarde
ANNEE=$(date +%Y)
MOIS=$(date +%m)
JOUR=$(date +%d)
SEMAINE=$(date +%W)
#Modification de la valeur de la variable $MOIS en fonction de son numéro
case $MOIS in
01) MOIS="Janvier";;
02) MOIS="Fevrier";;
03) MOIS="Mars";;
04) MOIS="Avril";;
05) MOIS="Mai";;
06) MOIS="Juin";;
07) MOIS="Juillet";;
08) MOIS="Aout";;
09) MOIS="Septembre";;
10) MOIS="Octobre";;
11) MOIS="Novembre";;
12) MOIS="Decembre";;
*) MOIS="ErreurDate";;
esac
#########################################
# CONFIGURATION
#########################################
# Identification de la base
USER=****
PASSWORD=****
#Création de l'arborescence
mkdir /etc/mysql/save/$ANNEE
mkdir /etc/mysql/save/$ANNEE/$MOIS
mkdir /etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE
mkdir /etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR
# Definition du repertoire racine
ROOT_DIRECTORY='/etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR'
# Type de produits
PRODUCTS[0]='sugarcrm'
PRODUCTS[1]='roundcubemail'
#########################################
# CONFIGURATION GLOBALE
#########################################
# Variable globale concernant le repertoire cible des dumps
TARGET_PATH='/etc/mysql/save'
#########################################
# Exportation des bases de donnees
# Pour chaque produit specifie en variable globale
for PRODUCT in ${PRODUCTS[*]}
do
# Dump de la base specifie suivant le produit et sa version
/usr/bin/mysqldump -u ${USER} -p${PASSWORD} ${PRODUCT} > ${TARGET_PATH}/${PRODUCT}
mv ${TARGET_PATH}/${PRODUCT} /etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR
done
#Copie de l'extraction sur le NAS
lftp ftp://****:****@***.***.***.*** -e "mirror -e -R /etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR /array1/mailbackup/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR/SaveBDD ; quit"
rm -r /etc/mysql/save/$ANNEE
Et mon crontab :
00 3 * * * root /usr/sbin/savebdd
PS: ne cherchez pas à comprendre ma logique pour faire des scripts, j'ai toujours fais des scripts biscornus :P
Merci de votre aide en tout cas.
J'ai un script d'export de base de données et de backup de ces dernières qui fonctionne manuellement. Mais il ne fonctionne pas lorsque je fais une tâche automatisée avec crontab.
Voici le script en question :
#!/bin/bash
#
# Backup des bases de donnees
#
#On récupère le jour, le numéro de semaine, le mois et l'année de la sauvegarde
ANNEE=$(date +%Y)
MOIS=$(date +%m)
JOUR=$(date +%d)
SEMAINE=$(date +%W)
#Modification de la valeur de la variable $MOIS en fonction de son numéro
case $MOIS in
01) MOIS="Janvier";;
02) MOIS="Fevrier";;
03) MOIS="Mars";;
04) MOIS="Avril";;
05) MOIS="Mai";;
06) MOIS="Juin";;
07) MOIS="Juillet";;
08) MOIS="Aout";;
09) MOIS="Septembre";;
10) MOIS="Octobre";;
11) MOIS="Novembre";;
12) MOIS="Decembre";;
*) MOIS="ErreurDate";;
esac
#########################################
# CONFIGURATION
#########################################
# Identification de la base
USER=****
PASSWORD=****
#Création de l'arborescence
mkdir /etc/mysql/save/$ANNEE
mkdir /etc/mysql/save/$ANNEE/$MOIS
mkdir /etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE
mkdir /etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR
# Definition du repertoire racine
ROOT_DIRECTORY='/etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR'
# Type de produits
PRODUCTS[0]='sugarcrm'
PRODUCTS[1]='roundcubemail'
#########################################
# CONFIGURATION GLOBALE
#########################################
# Variable globale concernant le repertoire cible des dumps
TARGET_PATH='/etc/mysql/save'
#########################################
# Exportation des bases de donnees
# Pour chaque produit specifie en variable globale
for PRODUCT in ${PRODUCTS[*]}
do
# Dump de la base specifie suivant le produit et sa version
/usr/bin/mysqldump -u ${USER} -p${PASSWORD} ${PRODUCT} > ${TARGET_PATH}/${PRODUCT}
mv ${TARGET_PATH}/${PRODUCT} /etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR
done
#Copie de l'extraction sur le NAS
lftp ftp://****:****@***.***.***.*** -e "mirror -e -R /etc/mysql/save/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR /array1/mailbackup/$ANNEE/$MOIS/Semaine_$SEMAINE/Jour_$JOUR/SaveBDD ; quit"
rm -r /etc/mysql/save/$ANNEE
Et mon crontab :
00 3 * * * root /usr/sbin/savebdd
PS: ne cherchez pas à comprendre ma logique pour faire des scripts, j'ai toujours fais des scripts biscornus :P
Merci de votre aide en tout cas.
A voir également:
- Certains comptes préfèrent examiner manuellement
- 2 comptes whatsapp double sim - Guide
- Télécharger mise à jour windows 11 22h2 manuellement - Accueil - Mise à jour
- Pourquoi certains sites sont inaccessibles - Guide
- Reinitialiser pc manuellement - Guide
- Mettre à jour manuellement vos pilotes de périphérique windows - Guide
7 réponses
C'est root qui lance le crontab.
Donc en début de ton script il te faut faire un su "propriétaire de la base", du genre :
su oracle
mieux
su - oracle
s'il y a des variables d'environnement à positionner...
puis tu déroules ton script même biscornu :P
sqlplus toto pwdtoto
...
...
Donc en début de ton script il te faut faire un su "propriétaire de la base", du genre :
su oracle
mieux
su - oracle
s'il y a des variables d'environnement à positionner...
puis tu déroules ton script même biscornu :P
sqlplus toto pwdtoto
...
...
salut,
crontab n'utilise pas de nom d'utilisateur. (ça existe, mais ailleurs)
donc , en tant que root
crontab n'utilise pas de nom d'utilisateur. (ça existe, mais ailleurs)
donc , en tant que root
crontab -eet, une fois dans l'éditeur
0 3 * * * /usr/sbin/savebdd
En fait si on ne mets pas de fichier log on reçoit un email
Je reçois ceci : /bin/sh: /usr/sbin/savebdd: Permission denied
Tu penses que si j'ajoute le log au crontab les infos seront plus détaillées ?
J'ai quelques scripts, ils fonctionnent tous ... Sauf celui ci :s
Je reçois ceci : /bin/sh: /usr/sbin/savebdd: Permission denied
Tu penses que si j'ajoute le log au crontab les infos seront plus détaillées ?
J'ai quelques scripts, ils fonctionnent tous ... Sauf celui ci :s
J'ai essayé avec un fichier log, j'ai le même message :
/bin/sh: /usr/sbin/savebdd: Permission denied
/bin/sh: /usr/sbin/savebdd: Permission denied
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Pardon je suis allé un peu vite.
Perso j'administrais plusieurs machines et Bdd, tous mes cron étaient lancés par root.
Donc dans ton cas si ça marche à la mimine, et si c'est le même utilisateur qui lance en cron, ça devrait fonctionner.
Tu as bien un pb de droits.
ATTENTION quand tu lances à la mimine des variables environnement sont positionnées. Ce qui N'EST PAS le cas en cron.
Tu peux être amené à les positionner en début de script du genre :
ORACLE_HOME=$ORA_HOME ; export ORACLE_HOME
ORACLE_SID=$ORA_SID ; export ORACLE_SID
Parsème ton script de echo, du genre
echo "Répertoire créés"
Tu auras les résultats dans &1 (ST_refE dans l'exemple ci-dessus)
&2 (TonFichierCompteRenduExécution contiendra lui les erreurs d'exécution)
@+
Perso j'administrais plusieurs machines et Bdd, tous mes cron étaient lancés par root.
Donc dans ton cas si ça marche à la mimine, et si c'est le même utilisateur qui lance en cron, ça devrait fonctionner.
Tu as bien un pb de droits.
ATTENTION quand tu lances à la mimine des variables environnement sont positionnées. Ce qui N'EST PAS le cas en cron.
Tu peux être amené à les positionner en début de script du genre :
ORACLE_HOME=$ORA_HOME ; export ORACLE_HOME
ORACLE_SID=$ORA_SID ; export ORACLE_SID
Parsème ton script de echo, du genre
echo "Répertoire créés"
Tu auras les résultats dans &1 (ST_refE dans l'exemple ci-dessus)
&2 (TonFichierCompteRenduExécution contiendra lui les erreurs d'exécution)
@+
Mais si cron.allow et cron.deny n'existe pas ça veut dire que c'est uniquement root qui peut executer cron non ?
J'ai ajouté root dans cron.allow .... Rien n'a changé :s
Je comprends pas, si root n'a pas la permission pour executer un script, qui en a la permission ? :s
Je rappel que j'ai quelques scripts, qui fonctionnent tous avec cron. Seulement celui ci me pose problème.
J'ai ajouté root dans cron.allow .... Rien n'a changé :s
Je comprends pas, si root n'a pas la permission pour executer un script, qui en a la permission ? :s
Je rappel que j'ai quelques scripts, qui fonctionnent tous avec cron. Seulement celui ci me pose problème.
Finalement en écrivant le dernier message j'ai trouvé la solution :
J'ai simplement fait ceci :
chown root mon/chemin/du/script
chmod 711 mon/chemin/du/script
J'ai supprimé le fichier cron.allow que j'avais crée avant.
Et maintenant il se lance avec cron sans pb.
Bizarre car j'avais bien crée le script avec root ... Mais bon
J'ai simplement fait ceci :
chown root mon/chemin/du/script
chmod 711 mon/chemin/du/script
J'ai supprimé le fichier cron.allow que j'avais crée avant.
Et maintenant il se lance avec cron sans pb.
Bizarre car j'avais bien crée le script avec root ... Mais bon
Merci d'avoir pris le temps de donner la solution.
Met un [Résolu] dans le titre ça aide ceux qui font des recherches.
Effectivement root n'a pas besoin de se trouver dans cron.allow.
J'ai pour habitude de mettre en exécutable (+x) les scripts qui le sont et j'évite de lancer par :
. ./script
ou
sh script
Désolé, je n'ai vraiment pas penser à un pb de droit sur le script lui-même.
Ton chown root mon/chemin/du/script me laisse plus perplexe dans la mesure où c'est le crontab de root qui lance un script appartenant à root...
Pour info lorsque un utilisateur lamda lance le script d'un autre utilisateur, il faut passer également le répertoire en (+x) au bon niveau suivant qu'il appartient au même groupe ou non. Dans ce cas le "x" au niveau du répertoire indique qu'il peut être parcouru...
Sinon la aussi "permission denied" :-)
BRAVO
Met un [Résolu] dans le titre ça aide ceux qui font des recherches.
Effectivement root n'a pas besoin de se trouver dans cron.allow.
J'ai pour habitude de mettre en exécutable (+x) les scripts qui le sont et j'évite de lancer par :
. ./script
ou
sh script
Désolé, je n'ai vraiment pas penser à un pb de droit sur le script lui-même.
Ton chown root mon/chemin/du/script me laisse plus perplexe dans la mesure où c'est le crontab de root qui lance un script appartenant à root...
Pour info lorsque un utilisateur lamda lance le script d'un autre utilisateur, il faut passer également le répertoire en (+x) au bon niveau suivant qu'il appartient au même groupe ou non. Dans ce cas le "x" au niveau du répertoire indique qu'il peut être parcouru...
Sinon la aussi "permission denied" :-)
BRAVO
15 19 * * 5 /home/proc2/stop_start refE >/home/proc2/cr/ST_refE 2> /TonFichierCompteRenduExécution