Lesson 29 of 60 intermediate

Packages, Cron & Routine Automation

Ops work is repetitive by design

Open interactive version (quiz + challenge)

Real-world analogy

Automation is how you stop being the hero who runs the same commands at midnight. Cron is the office alarm system — it doesn’t forget, doesn’t get tired, doesn’t call in sick. Your job is to write the alarm correctly.

What is it?

Scheduled automation with clean packaging, idempotent scripts, consistent logging, and monitoring is what turns a manual admin into a reliable operator. It’s how small teams run large environments.

Real-world relevance

A financial reporting job must export, upload, and notify every morning at 03:30. You write a bash script with set -euo pipefail, lock file, cron entry, log output to /var/log/report.log, and exit codes feeding into healthchecks.io. If anything fails, on-call is paged with context — not at 09:00 from an angry user.

Key points

Packages — install, update, remove — apt/dnf/yum/pacman install, upgrade, remove. Always apt update (or dnf check-update) first. Know how to list installed packages and find which package owns a file.
Cron syntax — minute hour day month weekday command. */5 = every 5. 0 3 * * * = daily at 03:00. Use /etc/crontab or per-user crontab -e. Always redirect output to a log or you’ll drown in emails.
systemd timers (modern alternative) — Many shops prefer systemd .timer units over cron — better logging via journalctl, dependency handling, and randomized delays. Know both names; cron is still dominant.
Idempotent scripts — A well-written automation runs safely if triggered twice. Use checks: mkdir -p, test -f before creating, lock files to prevent overlap. Broken idempotency = weekend pages.
Output, error, and exit codes — In Unix, 0 = success, non-zero = failure. Redirect stdout and stderr (>> /var/log/x.log 2>&1). Check exit codes in scripts ($?) and fail loudly — not silently.
Backup your changes before automation — Copy configs to config.bak before rewriting. Use version control (git) where practical. A 10-line script writing to /etc without backups is a future outage waiting to happen.
The golden rules of operator scripts — (1) One job, well-scoped. (2) Log every step. (3) Exit non-zero on any failure. (4) Use set -euo pipefail in bash. (5) Protect secrets (never echo passwords). (6) Document the cron line near the script.
Simple monitoring hook — Scripts should emit an exit code a monitoring system can notice. When a cron job exits non-zero, a healthcheck tool (healthchecks.io, Uptime Kuma) can alert. Without monitoring, failed cron jobs look invisible.

Code example

#!/usr/bin/env bash
# /usr/local/bin/nightly_report.sh
set -euo pipefail
LOCK=/tmp/nightly_report.lock
LOG=/var/log/nightly_report.log

# prevent overlapping runs
exec 9>"$LOCK"
if ! flock -n 9; then
  echo "$(date -Is) another run in progress" >> "$LOG"
  exit 0
fi

{
  echo "$(date -Is) START"
  /usr/local/bin/run_report.py --date "$(date +%F)"
  /usr/local/bin/upload_report.sh "/var/reports/$(date +%F).csv"
  echo "$(date -Is) OK"
} >> "$LOG" 2>&1

# cron line (visudo / crontab -e):
# 30 3 * * * /usr/local/bin/nightly_report.sh

Line-by-line walkthrough

1. Bash header line (shebang)
2. Script path comment
3. Safer bash options
4. Paths for lock and log
5. Blank separator
6. Lock-file logic header
7. Open FD 9
8. flock non-blocking
9. Early-exit with log if locked
10. Blank separator
11. Main work block
12. Timestamped START
13. Run report generator
14. Upload the report file
15. Timestamped OK
16. Redirect all output to log
17. Blank separator
18. Example cron line

Spot the bug

Cron entry (installed by a junior):
  * * * * * curl https://api.internal/kick > /dev/null

Need a hint?

How often does this run, and what goes missing if the script fails?

Show answer

This runs every minute — often far too aggressive. It discards stdout AND stderr, so errors are invisible. It has no lock file, so failures can overlap. Use sensible schedule (e.g., */5 at most), redirect stdout AND stderr to a log, add a lock file, and feed success/failure to a monitoring tool.

Explain like I'm 5

Computers are great at doing the same thing every day without getting bored. Cron is how you tell them ‘do this every night at 3’ and go to sleep. Write it carefully or it will ‘do this every second forever.’

Fun fact

Many real-world ‘legacy systems’ are just one cron job tied to one person’s laptop that ran for 8 years. The moment that person leaves, the business discovers it. Document your cron jobs.

Hands-on challenge

Write a bash script that runs once per hour, writes a timestamped line to a log, and only runs if a certain file exists. Add it to cron. Simulate overlap with a sleep and verify the lock file prevents double-runs.

More resources

Debian apt docs (Debian)
systemd timers (freedesktop.org)
Cron how-to (DigitalOcean)

Open interactive version (quiz + challenge) ← Back to course: IT Jobs Bootcamp