Mission 27 of 30
Scheduling Without Breaking Your Crontab
Design a scheduled task and test its command before touching crontab.
Learn cron syntax and safe scheduling concepts without requiring changes to your real user crontab.
Practice inside
~/linux-practice. Check your setup before you begin.
Prerequisite: Shell Scripting Control Structures
.
What you’ll practice
- Read cron format
- List current crontab
- Simulate scheduled work safely
The mental model
- cron runs commands on a schedule.
- crontab -r removes the whole user crontab, so avoid it while learning.
- A shell loop can simulate repeated work inside the sandbox.
Try it in your terminal
Read current crontab
Read-only system viewChecks that the crontab command exists before listing entries, and distinguishes a missing tool from an empty or inaccessible user crontab. Scheduling also requires a working cron-compatible service.
Run from ~/linux-practice
if ! command -v crontab >/dev/null; then
echo "crontab is not installed in this environment"
else
crontab -l 2>/dev/null || echo "No user crontab exists, or access is unavailable"
fi Safe scheduling simulation
Safe in practice folderSimulates repeated scheduled work without editing crontab.
Run from ~/linux-practice
cd ~/linux-practice
mkdir -p logs
for i in {1..3}; do echo "Simulated run at $(date)" >> logs/schedule-demo.log; sleep 2; done
cat logs/schedule-demo.log Dangerous cleanup example
Explanation onlyRemoves the entire user crontab. Explanation only; do not use as course cleanup.
Run from do not run
crontab -r Put it into practice
- Write out what this means: */5 * * * * command.
- Run the safe scheduling simulation.
Check your result
The command succeeds manually before any schedule is proposed.
Common mistakes
- You add one test job to crontab, decide to remove it, type `crontab -r`, and lose every scheduled task you had. The `-r` flag removes the entire crontab — not one entry. To edit safely, use `crontab -e` and delete just the line you added.
- You write `*/5 * * * * backup.sh` and it silently fails. Cron doesn't load your shell profile, so it doesn't know where `backup.sh` lives. Use absolute paths: `*/5 * * * * /home/user/scripts/backup.sh`. Same goes for any command the script calls.
Check your understanding
Explain these in your own words. If you’re unsure, revisit the examples before moving on.
- What does crontab -l do?
- Why is crontab -r dangerous for beginners?
Your practice, your pace
Loading saved progress…