Probleme crontab sur les Synology [MAJ 2]

    Sur plusieurs Synology, je dois ajouter des commandes pour les sauvegardes qui se lancent automatiquement. Je vais donc tout simplement les ajouter dans la crontab du système.

    Mais voilà, pas de commande crontab pour éditer la table des crons. Après quelques recherches sur les forums de Synology, le seul moyen de le faire est d’ajouter les commandes désirées dans le fichier ‘/etc/crontab’.

    Je les ajoute donc dans ce fichier à l’aide de la commande vi.

    Ensuite, il faut penser à redémarrer le démon crond. Pour cela, il faut exécuter la commande

    /usr/syno/etc/rc.d/S04crond stop
    /usr/syno/etc/rc.d/S04crond start

    Voilà. Tout fonctionne bien. Mes commandes sont bien exécutées à l’heure voulue 🙂

    Mais un problème est bien sûr survenu 🙂 Après un redémarrage, la crontab ne contenait plus mes lignes que j’avais rajoutées.

    Je retourne donc voir sur les forums de Synology. Cela arrive très souvent. Le problème survient si le fichier /etc/crontab contient des espaces. Il ne devriat contenir que des tabulations.

    Je vérifie donc toutes mes lignes dans ce fichier. Ensuite, je redémarre et là, toujours pareil. Toutes mes lignes rajoutées ont encore disparues !!!

    Après de nombreuses recherches, j’ai trouvé deux nouvelles solutions :

    1. A la place de modifier le fichier /etc/crontab, modifier le fichier /etc.defaults/crontab. Ensuite, il faut modifier le script de démarrage du démon crond situé dans /usr/syno/etc/rc.d/S04crond. A chaque démarrage, il faut recopier le fichier /etc.defaults/crontab en /etc/crontab. Mais cette solution fait modifier des scripts du système, je ne retiens donc pas cette solution.
    2. L’autre solution consiste à installer une nouvelle table cron à l’aide de la commande ipkg. Pour installer cette commande, regardez l’article suivant. Nous allons donc installer cette nouvelle crontab en lançant la commande suivante :
      ipkg install cron

      Une fois installé, nous pouvons maintenant utiliser la commande crontab pour éditer la table des crons.

      crontab -e
      0       22      *       *       *       root    /bin/sh /xxxxxxxxxx
      0       7       *       *       *       root    /opt/bin/killall rsync
      */3     7-20    *       *       *       root    /bin/xxxxxxxxxxx

      Voilà, notre crontab est maintenant installé. N’oublions pas de lancer ce nouveau démon crond. Pour cela, nous lançons la commande suivante :

      /opt/etc/init.d/S10cron start

      Pour vérifier si ce nouveau crond tourne correctement, nous exécutons cette commande :

      ps | grep cron
      3165 root      5384 S    /usr/sbin/crond 
      3817 root      1680 S    /opt/sbin/cron
      21374 root      2928 S    grep cron

      Nous avons donc terminé. Même après un redémarrage, nos lignes sont toujours présentes dans cette nouvelle crontab.

      Cette solution n’est pas optimale car elle maintient en mémoire deux crontab différentes. Cela pourrait poser des problèmes dans le futur si nous ne sommes pas assez vigilant. Mais à l’heure actuelle, c’est la seule solution que j’ai trouvé et qui fonctionne.

      Donc pour l’instant, je reste sur cette solution an attendant d’en trouver une meilleure.

    MISE A JOUR du 28 avril 2011

    Aujourd’hui, quel ne fut pas ma surprise de voir que les commandes de cette nouvelle crontab n’ont pas été appelées. La crontab installée par ipkg n’a pas fonctionnée. Donc je me relance dans de nouvelles recherches sur les forums et discussions avec différentes personnes. Un nouvelle solution l’est donc proposée. Elle modifie tout de même un fichier du système mais bon, elle a le gros avantage de ne pas ajouter un nouveau démon crond.

    Cette nouvelle solution propose de modifier le script de démarrage du démon crond /usr/syno/etc/rc.d/S04crond.sh

    #!/bin/sh
    #
    # S04crond.sh - startup script for crond
    #
    # This goes in /usr/syno/etc/rc.d and gets run at boot-time.
    
    CROND=/usr/sbin/crond
    
    case "$1" in
    
    start)
     if [ -x "$CROND" ] ; then
     mkdir -p /var/spool/cron/crontabs/
     # Added line 1 :
     rm /var/spool/cron/crontabs/*
     ln -sf /etc/crontab /var/spool/cron/crontabs/root
     # Added line 2 :
     ln -sf /volume1/admin/crontab /var/spool/cron/crontabs/admin
     echo "Starting crond..."
     $CROND
     fi
     ;;
    
    stop)
     echo "stop crond"
     kill -USR1 `cat /var/run/crond.pid` > /dev/null 2>&1
     ;;
    
    *)
     echo "usage: $0 { start | stop }" >&2
     exit 1
     ;;
    
    esac

    J’ai donc ajouté deux lignes dans ce script :

    • La première ligne permet de supprimer toutes les crontabs en place dans le répertoire /var/spool/cron/crontabs/.
    • La seconde ligne permet de mettre en place la nouvelle crontab en la copiant depuis un répertoire donné /volume1/admin/crontab

    ATTENTION : le fichier /volume1/admin/crontab doit oblogatoirement appartenir à root pour que cela fonctionne. les droits exacts sont : -rw-r–r–  1 root root  210 Apr 28 10:55 crontab

    Le fichier /volume1/admin/crontab contient donc les lignes suivantes :

    0       22      *       *       *       root    /bin/sh /xxxxxxxxxx
    0       7       *       *       *       root    /opt/bin/killall rsync
    */3     7-20    *       *       *       root    /bin/xxxxxxxxxxx

    Il ne nous reste plus qu’à supprimer le package cron que j’ai installé hier :

    ipkg purge cron

    Et redémarrer ensuite le démon crond

    /usr/syno/etc/rc.d/S04crond.sh stop
    /usr/syno/etc/rc.d/S04crond.sh start

    Pour vérifier que je n’ai plus que un seul démon crond en mémoire,  nous exécutons la commande suivante :

    ps | grep cron
    781   root    2444 S    grep cron
    17389 root    4652 S    /usr/sbin/crond

    REMARQUES

    1. J’ai choisi un répertoire dans le volume1, car ce sont les données utilisateurs qui y sont stockées et non les fichiers du système. Lors d’une mise à jour du firmware, ce fichier ne sera donc pas effacé !!
    2. A chaque mise à jour du firmware, le fichier d’init de crond ‘/usr/syno/etc/rc.d/S04crond.sh’ sera effacé. Il faudra donc penser à refaire les modifications. C’est le seul petit soucis de cette solution !!

    MISE A JOUR du 4 mai 2011

    La solution ci-dessus fonctionne très bien. Mais dans mon cas, cela a posé un petit problème.

    Avec cette méthode, les commandes de cette nouvelle crontab sont lancées en tant qu’utilisateur ‘admin’ et non ‘root’. Ce qui a pour effet que certaines commandes ne fonctionnent pas(car c’est obligatoirement l’utilisateur ‘root’ qui doit lancer ces commandes).

    J’ai donc fait une petite modification afin de corriger ce problème.

    Dans le script de démarrage ‘/usr/syno/etc/rc.d/S04crond.sh’, j’ai corrigé la deuxième ligne que nous avions rajoutée. Elle créée un lien symbolique vers le fichier ‘/volume1/admin/crontab’.
    Je la modifie afin que le contenu du fichier ‘/volume1/admin/crontab’ soit rajouté à la fin de la crontab de l’utilisateur ‘root’  ‘/var/spool/cron/crontabs/root’.

    Le nouveau script  

    ‘/usr/syno/etc/rc.d/S04crond.sh’ est donc :

     

     

    #!/bin/sh
    #
    # S04crond.sh - startup script for crond
    #
    # This goes in /usr/syno/etc/rc.d and gets run at boot-time.
    
    CROND=/usr/sbin/crond
    
    case "$1" in
    
    start)
     if [ -x "$CROND" ] ; then
     mkdir -p /var/spool/cron/crontabs/
     # Added line 1 :
     rm /var/spool/cron/crontabs/*
     cp /etc/crontab /var/spool/cron/crontabs/root
     # Added line 2 :
     cat /volume1/admin/crontab >> /var/spool/cron/crontabs/root
     echo "Starting crond..."
     $CROND
     fi
     ;;
    
    stop)
     echo "stop crond"
     kill -USR1 `cat /var/run/crond.pid` > /dev/null 2>&1
     ;;
    
    *)
     echo "usage: $0 { start | stop }" >&2
     exit 1
     ;;
    
    esac

    Je supprime l’ancienne crontab de l’utilisateur ‘admin’ dans le répertoire ‘/var/spool/cron/crontabs’.

     

    Il ne nous reste plus qu’à redémarrer le démon crond

     

    /usr/syno/etc/rc.d/S04crond.sh stop
    /usr/syno/etc/rc.d/S04crond.sh start

    Et voilà. Le fichier ‘/var/spool/cron/crontabs/root’ contient la concaténation des fichiers cron de l’utilisateur root et de l’utilisateur admin.

     

     

    Maintenant les commandes de l’utilisateur admin sont bien lancées par l’utilisateur ‘root’. Attention donc à ce que vous faîtes !!

     

     

     

     

     

     

     

    A propos Julien Redondo

    Directeur technique chez Nouveaux Territoires
    Lien pour marque-pages : Permaliens.

    3 Commentaires

    1. Hi Julian, just tried your solution and it’s not working for me .. well it works fine until syno reboots .. it wont start cron jobs until the cron deamon is manually restarted
      with these commands:
      /usr/syno/etc.defaults/rc.d/S04crond.sh stop
      /usr/syno/etc.defaults/rc.d/S04crond.sh start
      then it starts working again until reboot .. the cron jobs are there .. they are listed in /var/spool/cron/crontabs/root/crontab, but they are not executed until the cron deamon is manually restarted

    2. Sous DSM 4.x, le fichier /etc/crontab est regénéré à chaque reboot et intègre les commandes présentes dans le fichier /etc.defaults/crontab. Ce fichier doit avoir le format suivant:

      minutehourmdaymonthwdayrootcommand

      !! Attention: pas d’espace, uniquement des entre les différents champs !!

      Il suffit ensuite de redémarrer le NAS et le fichier /etc/crontab est correct.

      Remarque: le fichier /etc.defaults/crontab est remplacé en cas de mise à jour de DSM. Il vaut donc mieux garder une copie de sauvegarde dans /volume1

    3. Sous DSM 4.x, le fichier /etc/crontab est regénéré à chaque reboot et intègre les commandes présentes dans le fichier /etc.defaults/crontab. Ce fichier doit avoir le format suivant:

      minuteTABhourTABmdayTABmonthTABwdayTABrootTABcommand

      !! Attention: pas d’espace, uniquement des TAB entre les différents champs !!

      Il suffit ensuite de redémarrer le NAS et le fichier /etc/crontab est correct.

      Remarque: le fichier /etc.defaults/crontab est remplacé en cas de mise à jour de DSM. Il vaut donc mieux garder une copie de sauvegarde dans /volume1

    Laisser un commentaire