Travail cron quotidien non exécuté

10

Un aperçu rapide: J'ai un script qui sauvegardera quotidiennement mon référentiel de code source de SVN dans une archive tar pour ce jour. J'ai testé le script et il fonctionne très bien tant que je l'exécute en tant que sudo, en raison de la propriété du répertoire de sortie.

Donc, le problème est que je veux l'exécuter quotidiennement, donc je mets un lien vers celui-ci dans le répertoire /etc/cron.daily. Voici le contenu du répertoire.

thom@spenser:/etc/cron.daily$ ls -l
total 60
-rwxr-xr-x 1 root root   189 2011-09-14 02:21 apport
-rwxr-xr-x 1 root root 15535 2011-10-06 11:30 apt
-rwxr-xr-x 1 root root   314 2011-08-08 16:57 aptitude
lrwxrwxrwx 1 root root    24 2012-02-28 11:05 backup -> /usr/local/bin/backup.sh
-rwxr-xr-x 1 root root   502 2011-06-08 11:48 bsdmainutils
-rwxr-xr-x 1 root root   256 2011-10-06 04:04 dpkg
-rwxr-xr-x 1 root root   372 2011-10-04 16:50 logrotate
-rwxr-xr-x 1 root root  1353 2011-07-27 07:17 man-db
-rwxr-xr-x 1 root root   606 2011-08-17 09:16 mlocate
-rwxr-xr-x 1 root root   249 2011-06-24 05:36 passwd
-rwxr-xr-x 1 root root  2417 2011-07-01 17:25 popularity-contest
-rwxr-xr-x 1 root root   383 2011-09-30 15:09 samba
-rwxr-xr-x 1 root root  3594 2011-09-19 20:07 standard
thom@spenser:/etc/cron.daily$

Le problème est qu'il ne fonctionne tout simplement jamais. Voici les autorisations pour ce script:

thom@spenser:/etc/cron.daily$ ls -l /usr/local/bin/backup.sh 
-rwxr-xr-x 1 root root 260 2012-02-28 11:03 /usr/local/bin/backup.sh

Des idées?

bash cron

— Thom
source

2

Si possible, veuillez envisager de fermer certaines de vos autres questions ouvertes en sélectionnant la meilleure réponse (si elles en ont une). Nous avons besoin que les utilisateurs maintiennent leurs questions afin que le site puisse être un outil efficace pour la prochaine personne avec vos problèmes. Pour plus de détails sur les meilleures pratiques, lisez la FAQ sur les questions à poser .

— Bruno Pereira

37

J'ai essayé ça

run-parts --test /etc/cron.daily

Trouvé que mon fichier update.ubuntu n'est pas venu. J'ai également remarqué que mon fichier avait une extension (avec un point).

Étapes pour résoudre ce problème.

J'ai renommé update.ubuntu en update-ubuntu
Encore une fois run-parts --test /etc/cron.daily, cette fois, mon dossier est arrivé!

— D Durga Prasad
source

1

Ouais, ça m'a arrangé. Il n'aime pas les points dans le nom de fichier, renommer mon fichier de myscript.sh en myscript a fonctionné pour moi.

— Matt Parkins

3

Cela doit être plus élevé. J'ai fait enregistrer mon script en tant que "backup.sh" traditionnel. La suppression de la partie ".sh" l'a résolu. Merci beaucoup!

— David

Merci! Le gars / fille qui a décidé de supprimer implicitement les fichiers .sh du cron quotidien devrait avoir honte!

— Sylvain

Devrait être fouetté publiquement! ;-) Je me demande combien de temps les gens ont collectivement perdu à cause de cette décision ... Je me demande aussi s'il y avait une bonne raison à cela?

— xastor

3

Pourrait être l'une des nombreuses choses:

Chemin des racines:

Selon les commandes en cours d'exécution, vous devrez peut-être développer la variable PATH des utilisateurs root en plaçant la ligne suivante en haut de leur fichier crontab:

CHEMIN = / usr / sbin: / usr / bin: / sbin: / bin

src: https://help.ubuntu.com/community/CronHowto

Ou utilisez simplement les chemins d'accès complets à chaque commande de votre script: /bin/lsau lieu de lspar exemple. ( which lssur la ligne de commande pour les chemins).

Il y a un étrange bug concernant les points dans le nom de fichier signalé ici . Peut s'étendre au fichier auquel vous créez un lien, bien que cela semble peu probable.

Enregistrez-vous la sortie du fichier de sauvegarde? Mettez quelque chose comme ça sur la première ligne, pour aider à déterminer s'il ne fonctionne pas du tout ou s'il fonctionne mais échoue à un moment donné.

/bin/echo "Attempting to run backup" >> /path-to-home/backup.log

Vous pouvez également essayer d'ajouter directement le script au fichier crontab:

sudo -i
crontab -e
[add the next line to the file, then save and exit]
33 15 * * * /usr/local/bin/backup.sh

fonctionnera à 15h30 tous les jours si la machine est allumée. utilisez * * * * * pendant le test pour exécuter une fois par minute jusqu'à ce qu'il fonctionne.

— Sean
source

1

L'utilisation de chemins absolus dans les scripts est déconseillée. Si vous ne savez pas ce qu'est PATH, définissez-le vous-même dans le script. Voir les raisons pour lesquelles crontab ne fonctionne pas

— geirha

Lien utile, merci. La raison donnée de ne pas utiliser les chemins d'accès complets est la portabilité. C'est suffisant. Une autre solution raisonnable consiste à définir les commandes que vous utilisez au début du script, ainsi que d'autres configurations: LS = / bin / ls; SRC_DIR = / home / joe / src. Utilisez ensuite $ LS $ SRC_DIR. Garde tout défini en haut et en un seul endroit.

— Sean

Je trouve que pour réduire la lisibilité, et vous devez passer en revue chaque commande = / chemin / vers / pour chaque nouveau système sur lequel il devrait fonctionner. Sur un système, toutes les commandes dont vous avez besoin pourraient être dans / usr / bin, sur un autre certaines sont dans / bin, d'autres dans / usr / bin. Le simple fait d'avoir / usr / bin et / bin dans PATH en fait un non-problème. Sur une note latérale, les noms de variables doivent être en minuscules, sinon vous risquez de remplacer les variables de shell spéciales ou les variables d'environnement.

— geirha

re: noms de variables majuscules. J'ai toujours fait ça sans trop réfléchir, à cause des premiers scripts que j'ai vus faire. Mais vous avez raison, il n'y a pas de hausse et une possibilité de baisse. Merci de l'avoir signalé, d'avoir rompu cette habitude maintenant.

— Sean

1

Grep votre syslog pour des messages comme;

crond: (*system*) BAD FILE MODE

les fichiers doivent être limités à (est suffisant) à 644):

chmod 0644 /etc/cron.d/my_crontab

— Tom H
source