Loading...

VONDS ©

Lab 12: Schedule and Inspect Cron Jobs

Lab Index

Schedule a recurring backup task using a user crontab and verify that it is installed correctly. Validate the job with crontab inspection, identify where cron activity is logged, and understand the role of system-wide cron directories.

services troubleshooting core

Scenario

Your team needs regular backups to run automatically. You have been asked to schedule a daily backup job using cron, confirm it is present in the user’s crontab, and identify where you would check for evidence when troubleshooting job execution.

Operator context

Cron failures are often simple: the job was never installed, the schedule was wrong, or logs were never checked. This lab builds the habit of proving each piece with command output.

Objective

  • List the current user’s cron jobs.
  • Open the user’s crontab for editing.
  • Create a daily job to run /usr/local/bin/backup.sh at 02:00.
  • Verify the job is installed using crontab -l .
  • Identify where cron messages are logged on common distros.
  • Explain the purpose of /etc/cron.d/ .

What You’ll Practice

  • Inspecting user crontabs with crontab -l .
  • Editing user crontabs with crontab -e .
  • Cron time field basics (minute, hour, day-of-month, month, day-of-week).
  • Verifying job installation and troubleshooting using log locations.
  • Understanding system-wide cron entries in /etc/cron.d/ .

Walkthrough

Step 1 : List the current user’s cron jobs.
Command 
crontab -l

This confirms whether the user already has scheduled jobs. If no crontab exists, you will see a message indicating the crontab is empty or missing. 

# Example (no jobs yet):
crontab: no crontab for vonds
Step 2 : Open the user’s crontab for editing.
Command 
crontab -e

This opens the per-user crontab in an editor. The editor may vary by system configuration, but the goal is the same: install a cron entry under the user’s account. 

# Example message:
Editing crontab using nano. Use Ctrl+O to save, Ctrl+X to exit.
Step 3 : Add a daily backup job at 02:00.
Command 
0 2 * * * /usr/local/bin/backup.sh

Cron format is: MIN HOUR DOM MON DOW CMD . This entry runs at minute 0 of hour 2 every day of the month, every month, regardless of day-of-week. 

# Confirm the entry is present in the crontab file you saved:
0 2 * * * /usr/local/bin/backup.sh
Step 4 : Verify the job is installed.
Command 
crontab -l

Always re-list the crontab after editing. This proves your entry was installed and helps catch editing mistakes before you wait for the schedule to trigger. 

0 2 * * * /usr/local/bin/backup.sh
Step 5 : Identify where cron messages are logged.
Command 
# Common locations (distro-dependent):
/var/log/syslog
/var/log/cron.log

Log locations vary by distro and logging configuration. Debian/Ubuntu commonly record cron activity in /var/log/syslog . Some systems log cron to a dedicated /var/log/cron.log or include cron events in a general messages log. 

# Example evidence patterns you might see:
CRON[12345]: (vonds) CMD (/usr/local/bin/backup.sh)
Step 6 : Understand what /etc/cron.d/ is for.
Command 
ls -l /etc/cron.d/

/etc/cron.d/ holds system-wide cron jobs that are managed as separate files. Unlike user crontabs, entries here typically include an explicit user field so a job can run as a chosen account. 

# You should see one or more cron definition files (example):
anacron
e2scrub_all
php

Reference

  • crontab -l : Lists the current user’s scheduled cron jobs.
  • crontab -e : Edits the current user’s crontab in the configured editor.
  • MIN HOUR DOM MON DOW CMD : Standard cron schedule fields used in user crontabs.
  • /var/log/syslog : Common location for cron messages on Debian/Ubuntu systems.
  • /var/log/cron.log : Common dedicated cron log file on some systems.
  • /etc/cron.d/ : Directory for system-wide cron job definitions with an explicit user field.