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.
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.
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.
/usr/local/bin/backup.sh at 02:00.crontab -l./etc/cron.d/.crontab, not a file you edit directly.
crontab -l. If it is not listed, it will not run.
/etc/cron.d/ is for system-managed cron files that include an explicit user field.
crontab -lThis 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 vondscrontab -eThis 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.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.shcrontab -lAlways 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# 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)/etc/cron.d/ is for.
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
The editor may have exited without saving, or the crontab may have failed validation.
Re-run crontab -e, save, then confirm with crontab -l.
Cron runs with a minimal environment. Verify the script path is correct, the script is executable, and use absolute paths inside the script. Then check cron logs for execution evidence.
Environment differences are the usual cause. Missing PATH, missing variables, or relative paths
inside the script can break cron execution. Log output to a file to capture errors.
Your system may be using journald-only logging or a different syslog configuration. Search the journal for cron entries or confirm where your distro records scheduler activity.
This lab installs a scheduled job. If you do not want it to persist, remove the entry from the user crontab and verify it is gone.
crontab -l
crontab -e
crontab -l shows the expected schedule (or shows no entry after removal), and cron logs show execution evidence when the job runs.
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.