Comment déboguer un problème où cron n'exécute pas un script donné & # 8212; ou autre?

Question

J'ai un script Rails que j'aimerais exécuter quotidiennement. Je sais qu'il existe de nombreuses approches et qu'une approche script / runner mal conçue est mal vue par certains, mais elle semble répondre à mes besoins.

Cependant, mon script ne sera pas exécuté comme prévu.

Mon application réside dans / data / myapp / current et le script dans script / myscript.rb . Je peux l'exécuter manuellement sans problème en tant que racine avec:

/data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb

Lorsque je le fais, le fichier de log spécial ( log / myscript.log ) est consigné comme prévu:

Tue Mar 03 13:16:00 -0500 2009 Starting to execute script...
...
Tue Mar 03 13:19:08 -0500 2009 Finished executing script in 188.075028 seconds

Je l’ai paramétré pour fonctionner avec cron tous les matins à 4 heures. La crontab de root :

$ crontab -l
0 4 * * * /data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb

En fait, on dirait qu'il a été essayé de courir aussi récemment que ce matin!

$ tail -100 /var/log/cron
...
Mar  2 04:00:01 hostname crond[8894]: (root) CMD (/data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb)
...
Mar  3 04:00:01 hostname crond[22398]: (root) CMD (/data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb)
...

Cependant, mon fichier journal ne contient aucune entrée et les données à mettre à jour ne sont pas mises à jour. Les autorisations du fichier journal (à titre de test) ont même été définies sur une écriture globale:

$ ls -lh
total 19M
...
-rw-rw-rw- 1 myuser apps 7.4K Mar  3 13:19 myscript.log
...

Je cours sur CentOS 5.

Donc mes questions sont ...

1. Où puis-je rechercher des informations pour résoudre ce problème?
2. S'agit-il d'un problème SELinux? Existe-t-il un contexte de sécurité que je pourrais définir ou modifier pour résoudre cette erreur?

Merci!

Mettre à jour

Merci à Paul et à Luke. Il s’est avéré qu’il s’agissait d’un problème d’environnement et la capture de stderr dans un fichier journal m'a permis de détecter l'erreur.

$ cat cron.log 
/usr/bin/env: ruby: No such file or directory

$ head /data/myapp/current/script/runner 
#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../config/boot'
require 'commands/runner'

L'ajout de l'exécutable spécifique à Ruby à la commande a fait l'affaire:

$ crontab -l
0 4 * * * /usr/local/bin/ruby /data/myapp/current/script/runner -e production /data/myapp/current/script/myscript.rb >> /data/myapp/current/log/cron.log 2>&1

Answer 1

Par défaut, cron envoie sa sortie par courrier électronique à l'utilisateur qui l'a exécuté. Vous pouvez y regarder.

Il est très utile de rediriger la sortie des scripts exécutés par cron pour pouvoir consulter les résultats dans un fichier journal au lieu du courrier local d'un utilisateur aléatoire sur le serveur.

Voici comment rediriger stdout et stderr vers un fichier journal:

cd /home/deploy/your_app/current; script/runner -e production ./script/my_cron_job.rb >> /home/deploy/your_app/current/log/my_file.log 2>&1

La > > redirige la sortie standard vers un fichier. De plus, le 2 > & amp; 1 / code> redirige stderr vers la sortie standard de sorte que tous les messages d'erreur soient également consignés.

Ceci fait, vous pourrez examiner les messages d'erreur pour voir ce qui se passe réellement.

Answer 2

Le problème habituel lorsque quelqu'un découvre que son script ne s'exécutera pas dans un travail cron lorsqu'il s'exécutera à partir de la ligne de commande est qu'il repose sur une partie de l'environnement d'une session interactive mais que cron ne l'obtient pas. Certains candidats fréquents sont le "PATH". environnement et éventuellement "HOME".

Answer 3

Sous Linux, assurez-vous que tous les fichiers de configuration (/ etc / crontab, /etc/crond.{daily ,hourly,etc}/* et /etc/cron.d/*) ne peuvent être écrits qu'en tant qu'utilisateur root. pas de liens symboliques, sinon ils ne seront même pas pris en compte.

Pour autoriser les liens non root et / ou symboliques, spécifiez l'option -p dans le démon crond.