Cron – Running a cron job manually and immediately

cron

(I have already read How can I test a new cron script ?.)

I have a specific problem (cron job doesn't appear to run, or run properly), but the issue is general: I'd like to debug scripts that are cronned. I am aware that I can set up a * * * * * crontab line, but that is not a fully satisfactory solution. I would like to be able to run a cron job from the command line as if cron were running it (same user, same environment variables, etc.). Is there a way to do this? Having to wait 60 seconds to test script changes is not practical.

Best Answer

Here's what I did, and it seems to work in this situation. At least, it shows me an error, whereas running from the command line as the user doesn't show the error.

Step 1: I put this line temporarily in the user's crontab:

* * * * *   /usr/bin/env > /home/username/tmp/cron-env

then took it out once the file was written.

Step 2: Made myself a little run-as-cron bash script containing:

#!/bin/bash
/usr/bin/env -i $(cat /home/username/tmp/cron-env) "$@"

So then, as the user in question, I was able to

run-as-cron /the/problematic/script --with arguments --and parameters

This solution could obviously be expanded to make use of sudo or such for more flexibility.

Hope this helps others.

Related Solutions

Cron job fails silently

The usual problem with 'cron' jobs is that they have zero environment - unlike 'at' jobs which do copy your environment. When something works from the command line and not from 'cron', my experience is that 'environment' is one of the most common problems. Occasionally you run into another problem - 'cron' jobs are not run with a terminal, and occasionally programs get stroppy about this. However, this is in the 1% range compared with 99% for environment issues.

The other key technique I use is to always run a shell script from 'cron'; the shell script ensures that the environment is set correctly and then runs the real program. If a 'cron' job is giving me problems, I can then tweak the script to do useful things like this:

{
    date
    env | sort
    set -x
    ...what was there before adding the debug...
} >/tmp/cron.jobname.$$ 2>&1

This redirects all the output - standard output and standard error - to a file name. You can build timestamps into the filename if you prefer that to the process ID. Analyzing the log files often reveals the problems swiftly.

Linux – How to test a new cron script

From google search on path in crontab

root@pingu # cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

You basically want to set the PATH and then not have to worry about the variations. Also, the quick test is to run your script via SSH on all your boxes using the same environment variables.

Best Answer

Related Solutions

Cron job fails silently

Linux – How to test a new cron script

Related Topic