Reliable maintenance starts with knowing not only what a command should do, but when and under which environment it will run. This hands-on course teaches recurring scheduling with cron and one-time scheduling with at, while emphasizing the verification and error-capture habits that make unattended jobs observable.
You will read cron's five time fields, install a real user crontab, inspect system-wide scheduling directories, diagnose a deliberately failing job, and manage the at queue. The final challenge combines these skills in a small maintenance setup with a daily executable script, an appended error log, and a queued one-time task.
What You Will Learn
- Interpret cron's minute, hour, day-of-month, month, and day-of-week fields
- List, edit, install, and verify recurring jobs in a user crontab
- Inspect
/etc/crontab,/etc/cron.daily,/etc/cron.hourly, andrun-parts - Use absolute paths and redirect scheduled-job errors with
2>or2>> - Install and start
atd, then submit a one-time job withat - Inspect pending
atjobs by ID withatqand cancel them withatrm - Build an executable maintenance script and schedule it for a precise daily time
Who This Course Is For
This intermediate course is for Linux users, system administrators, DevOps learners, and developers who need to automate recurring maintenance or queue work for a later time. It is particularly useful for anyone responsible for backups, housekeeping, reports, or other commands that must run without an interactive terminal.
Prerequisites: Basic Linux terminal skills, including editing files, running commands with sudo, changing execute permissions, and using output redirection.
Learning environment: A LabEx Debian/Ubuntu-style Linux terminal with cron available; the course installs the at package and starts its atd service.
Frequently Asked Questions
What is the practical difference between cron and at?
Cron is for repeating schedules such as every minute or every day at 02:30. at queues a command for one future execution. The course has you verify both models through an installed crontab and the at job queue.
Do I edit system-wide cron configuration in this course?
You inspect /etc/crontab and the hourly and daily directories to understand run-parts, but the recurring jobs you create are installed in the labex user's crontab. This keeps hands-on scheduling separate from existing system maintenance entries.
Why do cron jobs use absolute paths and explicit log redirection?
Cron runs without an interactive terminal and usually with a minimal environment. Absolute paths remove directory ambiguity, while 2> and 2>> make failures visible in a file; the final challenge appends errors from the daily maintenance job to error.log.
