How to debug an issue of cron's not executing a given script — or other?

Question

I have a Rails script that I would like to run daily. I know there are many approaches, and that a cron'd script/runner approach is frowned upon by some, but it seems to meet my needs.

However, my script is not getting executed as scheduled.

My application lives at /data/myapp/current, and the script is in script/myscript.rb. I can run it manually without problem as root with:

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

When I do that, the special log file (log/myscript.log) gets logged to as expected:

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

I have it set to run with cron every morning at 4 am. root's crontab:

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

In fact, it looks like it's tried to run as recently as this morning!

$ 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)
...

However, there is no entry in my log file, and the data that it should update has not been getting updated. The log file permissions (as a test) were even set to globally writable:

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

I am running on CentOS 5.

So my questions are...

1. Where else can I look for information to debug this?
2. Could this be a SELinux issue? Is there a security context that I could set or change that might resolve this error?

Thank you!

Update

Thank you to Paul and Luke both. It did turn out to be an environment issue, and capturing the stderr to a log file enabled me to find the error.

$ 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'

Adding the specific Ruby executable to the command did the trick:

$ 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

By default cron mails its output to the user who ran it. You could look there.

It's very useful to redirect the output of scripts run by cron so that you can look at the results in a log file instead of some random user's local mail on the server.

Here's how you would redirect stdout and stderr to a log file:

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

The >> redirect stdout to a file, and and the 2>&1 redirects stderr to stdout so any error messages will be logged as well.

Having done this, you will be able to examine the error messages to see what's really going on.

Answer 2

The usual problem when somebody discovers their script won't run in a cron job when it will run from the command line is that it relies on some piece of the environment that an interactive session has but cron doesn't get. Some frequent candidates are the "PATH" environment, and possibly "HOME".

Answer 3

On Linux, make sure all the config files (/etc/crontab, /etc/crond.{daily,hourly,etc}/* and /etc/cron.d/*) are only writeable to user root and are not symlinks, otherwise they will not even be considered.

To allow non-root and/or symlinks, specify the -p option to the crond daemon.