How to run a cron job manually

When scheduling a cron job you sometimes will find that the job works perfectly when run from the terminal, but fails when cron runs it at the scheduled time. This guide will show you how to run a cron job manually and immediately, directly from your terminal and exactly the way cron does.

1. Start with the correct user account

If the cron job is scheduled in your user crontab (e.g. crontab -e) the command will be run as you, not by root.

If the job is in a systemwide crontab like /etc/crontab or a file in /etc/cron.d/, the line has a username between the schedule and the command. That field is required. It does not default to root. In this example, the job is run as user dataproc:

$ cat /etc/crontab
4 5 * * * dataproc /home/crons/reporting-snapshot.py

Scripts dropped in /etc/cron.hourly and the other cron.* directories have no user field, and they run as root. On Debian and Ubuntu that is because /etc/crontab starts them with run-parts. On Red Hat, cron.hourly is started from /etc/cron.d/0hourly, and the daily, weekly, and monthly directories go through anacron. The five locations are in where cron jobs are saved.

After you determine the user account cron is using to run your job, move on to step 2.

2. Use the right shell

The shell is the application that prints your command prompt and executes your commands. The most common shell in modern linux distributions is bash. When you run a command from your terminal you're asking bash to start the process and display the output. When cron invokes your commands, it uses sh by default, and there are a few important differences:

• When you login to a terminal your .bashrc and .bash_profile scripts are executed automatically. This doesn't happen when cron runs your command so any environment variables created here will be missing in your cron jobs.
• Bash has special built-ins and features that will cause syntax errors under cron.

On Debian and Ubuntu that sh is dash. The variants are in crontab environment variables.

Running a command with /bin/sh can be done several ways and in this guide we will be passing the command in as a string, like this example that will use /bin/sh to print a Hello World:

$ /bin/sh -c "echo 'Hello World'"
Hello World
$

Adding a SHELL=/bin/bash declaration at the top of your crontab will give you modern bash features but will not fix problems with .bashrc and .bash_profile

3. Know where to start the job

Cron starts each command from the selected user's home directory and in the example from step 1, the dataproc job will be run from /home/dataproc.

That might not be the end of it - your crontab command itself might customize the working directory with a cd, so check that too. How cron picks the directory is covered in the crontab working directory.

$ crontab -l
4 5 * * * cd /home/crons && ./reporting-snapshot.py
$

4. Conclusion

Combine these 3 steps in a single command to create a testing environment for your cron job with the same user, shell, and directory cron will use.

$ sudo -u <USER> /bin/sh -c "cd ~ && <COMMAND FROM CRONTAB>"

That reproduces the user, sh, and the home directory. It does not copy every variable cron sets. When you are checking syntax, including bash-only features that cron's sh will reject, stay with this one-liner.

CronitorCLI's cronitor shell is a narrower check. It takes one command per invocation, starts that command in your home directory, and sets SHELL=/bin/sh, HOME, and CRONITOR_EXEC=1. It does not set PATH, and it does not switch users. If /bin/bash is installed, the command runs as bash -c, so bash-only syntax that would fail under cron can succeed here. Bash then falls back to its built-in default PATH. Cron's PATH is short, typically /usr/bin:/bin, and a bit longer on cronie 1.7 and later. Bash's default differs from cron's: it always includes /usr/local/bin, and on Debian it also includes the current directory. A "command not found" caused by cron's PATH may not reproduce here. A /usr/local/bin/node job can work in cronitor shell and still fail under cron. On Debian a bare script name in the home directory can do the same, because this shell starts in ~. Use an absolute path, or set PATH at the top of the crontab. Use cronitor shell to catch a missing variable or a relative path. For an sh syntax check, or for another user's crontab, use the sudo -u form above.

$ cronitor shell

If the command works here and still fails on the schedule, continue with debugging cron jobs.