Setting up cron jobs

How to list the cron jobs for a user

After creating a cron job, I would recommend you confirm the jobs were saved correctly. You can do this by running crontab -l to list the cron jobs for the current user.

Changing the editor crontab uses

If you're like me and are still not used to using vim or vi for editing, you can change the editor crontab uses like so:

EDITOR=nano crontab -e

Common cron job errors

While being a deceptively simple-looking table, there's a lot that can go wrong with setting up your cron jobs.

Incorrect syntax

Probably the most common issue.

Folks often forget the specifics of cron job schedule syntax or make typos, causing cron to either not run the job or run it at the wrong times. Always double-check your syntax and test it out if possible.

You can use OnlineOrNot's free cron schedule expression helper to double check your syntax.

Permissions issues

Folks sometimes forget that a cron job will run (by default) as the user who created it and with that user's permissions.

You can run a cron job as a specific user, using the following syntax:

* * * * * username_to_run_as_here command_to_be_executed_here

If the user doesn't have permission to execute a script or command, the cron job will fail. Always ensure the user has the correct permissions for the script you want to run.

Ignoring output and error messages

By default, cron sends the output of the job and any error messages to the user's mail on the system. Ignoring these messages or not redirecting them to a log file can lead to missing crucial information about why a job failed.

Incorrect file paths

It's common to see cron jobs fail because of incorrect file paths. Always use absolute paths for commands and files to avoid any ambiguity.

For example, instead of ~/myscript.sh, use /home/username/myscript.sh.

Not considering environment variables

Cron jobs run in a limited environment, which means that they may not have access to all the same paths and variables as your user. This is often overlooked and can cause a cron job to fail because it can't find a particular command or doesn't have some other environment variable it needs.

In some Linux distributions, like Ubuntu and Debian, you can even define environment variables inside the crontab file, like so:

SOME_SECRET=this-is-secret

* * * * *   run_command_with_secret

It's worth noting that variables in your environment variables defined in your crontab won't be substituted (as in bash), so PATH=/usr/local/bin:$PATH would be interpreted as-is, while environment variables defined in the command will work as expected.

Overlapping cron jobs

Scheduling too many jobs, or jobs that take a long time to execute can lead to overlapping executions, which might lead to high CPU usage, data corruption, or other unexpected behaviors.

Always make sure to give your jobs enough time to complete before the next one starts.

Forgetting time zones

Folks often overlook the system’s time zone when configuring cron jobs.

If your tasks are time-sensitive or coordinated across different time zones, this could lead to unexpected behaviors. Always know what time zone your server is using.

You can run date +%Z to get the system's timezone.