You need to capture the elusive crontab output so you can see what it is complaining about.
Add -x to your shebang for verbose output in your script:
Set the cron job to execute more frequently while you troubleshoot it:
*/1 * * * * root /home/absolute/runsikulix -r /home/absolute/auto/test.sikuli
Crontab should be logging to /var/log/syslog by default. Run a
grep CRON /var/log/syslog and check the output. If you see your job executing then you can
tail -f the syslog when cron runs and see what it is complaining about.
- If the output is not verbose enough you can reconfigure cron to output to a log file following these instructions. This is the "proper" way to do that:
Configuring crontab to log to a file...
This should show you each step that crontab is executing so you can see where its failing. I will note that crontab's environment is pretty slim and you should be using full instead of relative paths in your script since any binaries you call out may or may not be available in your path when it runs. Crontab is funny like that. To get around this you can either add paths to your script:
...or you can call out each binary using it's full path:
/bin/echo "say something" && /bin/which java
You can also call a user's environment inline:
0 5 * * * . /root/.profile; /home/absolute/runsikulix -r /home/absolute/auto/test.sikuli
Here is a sample script in Ruby template format that runs under root's crontab that illustrates some workarounds for dealing with the environment issues: