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 !!