Why some cron jobs fails to execute
There's one simple thing every system administrator should take into account, when settings up cron jobs, and which I - to my shame - didn't know until now.
When you setup a cron job, especially for a root user, I guess, your command runs in a very limited environment (basically, not paths and other variables set). So if you have a command in /usr/local/bin directory and can "test" it executes just fine from command line - it doesn't mean the same exact command will be executed successfully when running as a cron job!
Same goes for setting up and "testing" cron jobs with Webmin. You can click the "Run Now" button in Webmin's cron jobs manager, and the command will run just fine, generating output you expect - but when running as a cron tab job, your command might NOT work at all.
The problem, as outlined above, is that not all paths you expect to be set are actually set for cron jobs.
How to confirm?
You can just read root's email (or cron job owner's email). In terminal just type "mail" and then enter a number of message you want to read. Here's the output for a problematic setup:
& 5000
Message 5000:
From root@……… Thu Nov 1 00:02:01 2007
Date: Thu, 1 Nov 2007 00:02:01 +0900
From: root@……….. (Cron Daemon)
To: root@……….
Subject: Cron <root@www> monit validate #relaunches monit if needed
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>/bin/sh: monit: command not found
The solution? Just specify full path to the command!
In my case, monit is located in /usr/local/bin/ directory, which clearly is not defined in the PATH. So, it's /usr/local/bin/monit validate and you're set.
So, use full paths to your commands, and inside shell scrips (or set paths), and don't really trust Webmin' Cron Run Now command.