Cron Jobs

Cron runs commands on recurring schedules without an interactive shell. Automation repeats both correct behavior and mistakes, so test the command, use explicit paths, constrain privileges, and plan logging and failure notification before scheduling it.

Reading a Crontab Entry

A user crontab entry contains five time fields followed by a command:

30 8 * * * /home/pete/scripts/change_wallpaper

From left to right, the fields are minute, hour, day of month, month, and day of week. This example runs at 08:30 according to the cron daemon's applicable timezone. An asterisk means every permitted value in that field.

When both day-of-month and day-of-week fields are restricted, many cron implementations run when either field matches. Confirm local semantics before building a schedule that uses both.

Managing a User Crontab

Edit the current user's crontab with:

$ crontab -e

List the installed entries before and after a change:

$ crontab -l

crontab -r removes the user's entire crontab and may do so without an editor. Do not use it to remove one line; edit the crontab and verify the remaining entries.

Accounting for the Cron Environment

Cron commonly supplies a limited environment and a noninteractive shell. Use absolute command and file paths, set required variables explicitly, and do not depend on aliases, a current terminal directory, or shell startup files.

Redirect standard output and error to a controlled log or use a notification mechanism appropriate to the system. Protect credentials with restrictive permissions and avoid embedding secrets directly in a crontab command.

Testing and Preventing Overlap

Run the script manually as the same user with a similarly minimal environment. Make it return useful exit statuses and write timestamped results. After installation, wait for a harmless test schedule or controlled run and verify the actual side effect and logs.

If one run might last longer than its interval, design for concurrency or use a locking mechanism such as flock where available:

*/5 * * * * /usr/bin/flock -n /run/user/1000/report.lock /home/pete/bin/report

Choose a lock path the job user may safely create, and decide whether skipped runs are acceptable. Cron does not automatically guarantee that only one instance runs.

Choosing the Right Scheduler

Cron is appropriate for simple recurring commands. Systemd timers can provide dependency integration, persistent catch-up behavior, randomized delay, and journal logging on systemd hosts. Application or cluster schedulers may be safer when a job must run exactly once across multiple machines.

Summary

You can now operate a recurring cron job with explicit schedule and execution assumptions.

1. Read the five time fields in their defined order.
2. Inspect and edit user crontabs without deleting unrelated jobs.
3. Define paths, environment, logging, and credential handling.
4. Test as the job user and protect against unwanted overlap.
5. Choose a scheduler that matches host and coordination requirements.