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.
Process Utilization · Lesson 8
Cron Jobs
Learn how to create, inspect, test, and safely operate recurring jobs with cron.
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.
When does 30 8 * * * command run?
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.
Which command lists the current user's installed cron 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.
Why should a cron command use explicit paths and environment settings?
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.
What risk exists when a job takes longer than its schedule interval?
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.
Why might ordinary per-host cron be unsuitable for a clustered exactly-once job?
Lesson complete
You finished Cron Jobs
You can now operate a recurring cron job with explicit schedule and execution assumptions.
Read the five time fields in their defined order.
Inspect and edit user crontabs without deleting unrelated jobs.
Define paths, environment, logging, and credential handling.
Test as the job user and protect against unwanted overlap.
Choose a scheduler that matches host and coordination requirements.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account