Problème CRON: Multiple exécution d'un script

Bonjour,

Je rencontre un problème avec l’installation d’un CRON. En effet, celui-ci devrait lancer un script seulement une fois à une heure bien précise. En d’autres termes il doit exécuter un script de backup tous les jours à 01h00. Voici l’instruction donnée:

`* 1 * * * sh /home/dropbox/backmeup/bin/backup.sh -u user -i /home -o /home/dropbox/Dropbox/backups`

J’aurais aimé joindre un fichier, mais je n’ai pas les permissions pour cela. Désolé pour le pavé. Voici le script /bin/sh:

PROG_NAME=$(basename $0)
USER=""
INPUT_DIR=""
OUTPUT_DIR=""
SCRIPT_DIR=$(dirname $(realpath "$0"))

while getopts u:p:i:o: OPTION
do
    case ${OPTION} in
        u) USER=${OPTARG};;
        i) INPUT_DIR=${OPTARG};;
        o) OUTPUT_DIR=${OPTARG};;
        ?) echo "Usage: ${PROG_NAME} [ -u mysql_username -i input_dir -o output_dir ]"
           exit 2;;
    esac
done

#Variable with current date and time (for the file name)
DATE_NAME=$(date +'%Y-%m-%d-%H-%M-%S')

#The temp location to copy all files
TEMP_DIR="/tmp"
TEMP_BACKUP_DIR="$TEMP_DIR/$DATE_NAME"
TEMP_SITES_BACKUP_DIR="$TEMP_BACKUP_DIR/sites"
TEMP_NGINX_CONFIG_DIR="$TEMP_BACKUP_DIR/configs/nginx"
TEMP_MYSQL_DATABASE_BACKUP_DIR="$TEMP_BACKUP_DIR/databases"

#Create the directories above
mkdir -p $TEMP_SITES_BACKUP_DIR
mkdir -p $TEMP_NGINX_CONFIG_DIR
mkdir -p $TEMP_MYSQL_DATABASE_BACKUP_DIR

if [ ! -d "$OUTPUT_DIR" ]; then
    mkdir -p $OUTPUT_DIR
fi

echo "Backing up sites and config"
cd $INPUT_DIR;
tar -zcf "$TEMP_SITES_BACKUP_DIR/home.tar.gz" --exclude=dropbox "."
tar -zcf "$TEMP_NGINX_CONFIG_DIR/configs.tar.gz" "/etc/nginx/sites-available"

echo "Backing up databases"
#This will backup all my databases

sh $SCRIPT_DIR/dump-all-databases.sh  -u $USER -o $TEMP_MYSQL_DATABASE_BACKUP_DIR -z

cd $TEMP_DIR
tar -cf "$OUTPUT_DIR/$DATE_NAME.tar" $DATE_NAME
rm -rf $TEMP_BACKUP_DIR

OLD_BACKUP_FILES=`ls $OUTPUT_DIR -t | tail -n +31`

if [ -n "$OLD_BACKUP_FILES" ]
then
    echo "Removing old backup files $OLD_BACKUP_FILES"
    rm $OUTPUT_DIR/$OLD_BACKUP_FILES
fi

# Remove old backup archives (3 days)

find $OUTPUT_DIR -mtime +3 -exec rm {} \;

À l’exécution manuelle, avec les mêmes paramètres, ce script s’exécute avec quelques retours console inattendus. Ces retours concernent les permissions relatives à certains fichiers cachés - tel que .viminfo - contenus dans une répertoire /home. Autrement, tout se passe à merveille à la condition que j’exécute manuellement ce script.

Si ce script est appelé par le CRON alors celui-ci s’exécute un nombre indéterminé de fois (beaucoup à en juger le nombre d’archives créées) puis le processus @dropbox permettant une synchronisation avec un compte Dropbox fini par s’arrêter.

Quelqu’un aurait une idée d’où viendrait le problème ?

  • Problème de scop relatif au CRON. J’ai lu quelques pistes sur le net là dessus, mais je ne comprends pas encore très bien les principes fondamentaux pour juger ;
  • Dysfonctionnement dû aux retours console ;
  • Erreur de syntaxe ou de conception dans le script.

J’avoue me casser les dents depuis des mois pour créer un système de backup fiable pour mon VPS personnel. Cette solution me paraît convenable pour mes modestes besoins, c’est pourquoi je fais appel à vous pour me dépanner !

Excellente journée !

A supposer que le script possède bien un shebang du type !/bin/sh pourquoi le repréciser dans ta cron ?

Y a t’il un raison particulière à utiliser le bourne shell plutôt que Dash ou Bash ?

As-tu essayer de placer un peu de log durant exécution, avec par exemple du tee

Par exemple

ls -la | tee -a logfile.txt

Renvoi le résultat de ls -la dans un fichier nommé logfile.txt.

Pareil pour le debug, si tu utilisé bash tu pourrais lancer manuellement ton script avec l’option -x afin de corriger (voir exclure ce qui ne peux pas/doit pas être sauvegardé).

Afin de contrôler le retour ducommande tu peux utiliser ce genre de mécanique :

RETOUR=$(echo $?)

Attention a l’utilisation des doubles quotes et simple quote, ce n’est pas strictement pareil.

Bonjour,

Ce cronjob sera exécuté à chaque minute entre 1:00 et 1:59

Pour une seule exécution quotidienne à 1:00:
00 01 * * * sh /home/dropbox/backmeup/bin/backup.sh -u user -i /home -o /home/dropbox/Dropbox/backups

C’est: Minute Heure DayOfMonth Month DayOfWeek

Salut Clochette et Sputnik93, merci de vous attarder sur le sujet :slight_smile:

Parce que je ne suis pas expérimenté dans le scripting et que je n’avais pas fait attention à ce que j’écrivais. Maintenant que tu le dis, effectivement, l’instruire deux fois n’a pas réellement de sens :sweat_smile: J’ai délaissé la précision dans le cron au profit du shebang dans le fichier.

Vraiment aucune issue d’une mûre réflexion, je le reconnais. Étant loin d’être expert en la matière, je ne me pose pas toujours les bonnes questions… Je vais me documenter sur le sujet et je ferai le choix qui me paraît le plus approprié. Merci pour cette remarque, elle m’apprendra quelque chose !

Absolument pas, mais tu as raison, il faut que j’en revienne aux principes du debug. J’ai donc ajouté des sorties vers un fichier de debug de tout ce qui peut engendrer une sortie de commande. Aucune erreur n’est remontée du côté de l’exécution du script.

Je suis désolé, je ne suis pas sûr de bien comprendre ce que tu m’explique. Je peux te demander de reformuler ? J’ai comme l’impression de devoir comprendre quelque chose d’utile :sweat_smile:

Oups, je ne l’avais pas vu celle là ! Je vais devoir rejouer avec du cron, je ne le maîtrise pas si bien que je l’imaginais. Je vais tester cette modification, mais on peut effectivement dire que l’erreur vient de là. Si le processus s’arrête c’est qu’il doit pomper toute la ressource serveur en l’espace d’une heure… ce qui explique l’arrêt du processus, je me trompe ?

Merci à vous deux pour vos remarques et solutions ! Je confirmerai le succès de l’opération un tout petit peu plus tard lorsque je serai certain que tout se déroule comme je l’entend !
Bonne fin de journée !

Où vois-tu l’utilisation du Bourne shell ? sh (/bin/sh) est un lien symbolique qui pointe vers le shell système, qui est dash par défaut depuis plusieurs versions de Debian.