How to run a cron job manually, now

Cron has no command to run a job now: you run its command yourself. The catch is that from your terminal it runs with another user, another shell and other variables than in cron, so it can work for you and fail in cron. These are the ways to run it now, from the quickest to the closest to what cron does.

1. Copy the command and run it as the crontab’s user

Find the line with crontab -l (or sudo crontab -l for root’s crontab, and cat /etc/crontab /etc/cron.d/* for the system’s). The command is everything after the five fields of the schedule, and after the user in /etc/crontab and /etc/cron.d/.

When you copy it, turn each \% back into %: cron removes the backslash before running the command. Then run it as the crontab’s user, with /bin/sh as cron does:

sudo -u www-data -H sh -c '/path/to/job.sh'
echo $?

For root’s crontab, sudo sh -c '...', and for your own, sh -c '...'. echo $?, right after, shows the command’s exit code: 0 means it went well, and another number usually means it failed (what each one means is in cron job exit codes). If the command works like this and fails in cron, the difference is in the environment: go to step 2.

2. Run it with cron’s environment

Cron doesn’t read the user’s profile: it starts the command with a few variables, a short PATH and the user’s home directory as the working directory. To run it almost as cron does, with the same user as in step 1 (here www-data, whose home directory is /var/www; getent passwd www-data shows it):

sudo -u www-data env -i HOME=/var/www LOGNAME=www-data SHELL=/bin/sh PATH=/usr/bin:/bin \
  /bin/sh -c 'cd "$HOME" && /path/to/job.sh' < /dev/null
echo $?

For your own crontab, leave out sudo -u www-data and use your variables: HOME="$HOME" LOGNAME="$USER".

< /dev/null leaves it without input, as in cron: a command that asks for something, like a password or the confirmation of an SSH host key, fails here as it would in cron.

Cron may set other variables, depending on the system and on the crontab. To see how its environment differs from your terminal’s, add this line to the same crontab, wait a minute and remove it:

* * * * * env > /tmp/cron-env

Then, in your terminal and as the same user, compare the two:

diff <(sort /tmp/cron-env) <(env | sort)

The lines with < are cron’s, and the ones with > are your terminal’s: usually PATH, SHELL and the variables of your profile. Set the ones the job needs in the crontab or in the script (the common causes are in why your cron job isn’t running). To reproduce the real run, with all of cron’s environment, let cron run it, in step 3.

3. Let cron run it in two minutes

The surest test is to let cron run it. Copy the line with a schedule a couple of minutes ahead: if it’s 14:32, 34 14 * * *. Cron reads the change when you save with crontab -e, runs the line at 14:34 with its real environment and its MAILTO, and you can follow it in the cron logs. Remove the copy afterwards.

The jobs of /etc/cron.daily and the other directories

Those scripts run with run-parts. To run all of a directory now, or just one script:

sudo run-parts /etc/cron.daily
sudo /etc/cron.daily/logrotate; echo $?

On Debian and Ubuntu, run-parts skips the files with a dot in their name, like backup.sh: if a script doesn’t run on its own, that may be why.

systemd timers

A timer starts a service, and that service can be started now:

sudo systemctl start backup.service
systemctl status backup.service
journalctl -u backup.service -n 50

systemctl status shows how it ended, with its exit code in the status= of the process, and journalctl shows its output. systemctl list-timers --all shows the timers and their services (more in how to list the cron jobs).

Kubernetes and Docker

A Kubernetes CronJob can create a job now, with the same template:

kubectl create job --from=cronjob/backup backup-manual
kubectl get job backup-manual
kubectl logs job/backup-manual

kubectl get job shows whether it completed, and kubectl logs shows its output.

In a Docker container, run the command with docker exec, keeping in mind that cron in the container may not see the container’s variables (see how to run cron jobs in a Docker container). docker exec ends with the command’s exit code:

docker exec my-container /path/to/job.sh; echo $?

Know when it fails on its own

Running it by hand tells you whether it works now. To know when it fails at 3 in the morning, the job has to report each run: when it starts, when it ends and with what code.