🔔 धडा 10 — Scheduling आणि automation: घंटा

📍 तुम्ही इथे आहात: 12 पैकी धडा 10 · पुढे: lesson-11-ci-and-containers

📦 या ब्रँचमध्ये काय आहे

धडे 01–10. तिथे कोणी नसताना script चालवणे — आणि ती दोनदा, गुपचूप किंवा पसाऱ्यात चालू नये यासाठीच्या चार सवयी.

bin/backup.sh — रात्रीचे काम: tar → verify → rotate, एक lock, एक log

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

पहाटे दोन वाजता घंटा वाजते आणि केअरटेकर backup चे कार्ड चालवतो. कोणी पाहत नसते, म्हणून कार्डने हे करायलाच हवे: एका वेळी एकदाच चालणे (दारावर कुलूप), पुन्हा चालवणे सुरक्षित असणे (idempotent — तोच निकाल), काय झाले ते लिहून ठेवणे (वेळांसह log), आणि काहीही चुकले तर मोठ्याने fail होणे (धडा 08 मधला strict mode). घंटा स्वतः बहुतेक machines वर cron असते, आधुनिक Linux वर systemd timer, किंवा CI मधले schedule.

🗺️ आकृती

flowchart LR
  C["🔔 cron: 0 2 * * *"] --> B["backup.sh"]
  B --> L{"mkdir lock?"} -->|exists| D["die: already running"]
  L -->|ok| T["tar → verify → rotate"] --> U["rmdir lock (trap)"] --> G["log: kept 5"]

❓ काय

crontab -e, पाच fields: min hour day month weekday — 0 2 * * * रोज 02:00 ला, */15 * * * * दर 15 मिनिटांनी. crontab -l यादी दाखवतो.
cron चे environment अगदी मोकळे असते: मूलभूत गोष्टींपलीकडे PATH नाही, तुम्हाला अपेक्षित HOME नाही, cwd म्हणजे /. absolute paths वापरा, crontab मध्ये PATH set करा, output log मध्ये redirect करा किंवा MAILTO set करा.
Locks: mkdir "$LOCK" || die atomic आहे; Linux वर flock; trap मध्ये सोडा. Idempotent: दोनदा चालवा, तीच स्थिती. Retention: N ठेवा.
systemd timers: OnCalendar=daily, logs journalctl -u मध्ये, overlaps नाहीत, downtime नंतर राहिलेले run भरून काढतात. cloud मध्ये: EventBridge, Kubernetes चा CronJob.
तुम्ही जे बनवले ते तपासा: किमान tar -tzf; दर महिन्याला restore ची तालीम.

🤔 का

"backup महिनोनमहिने चालला" आणि "backup महिनोनमहिने रिकामा होता" बाहेरून सारखेच दिसतात. फक्त log, verification आणि अधूनमधून केलेले restore त्यांच्यातला फरक सांगतात.

🔧 कसे (या repo मध्ये)

backup.sh: defaults सह KEEP, DEST, SRC; mkdir "$LOCK" || die; trap 'rmdir "$LOCK"; log done' EXIT; timestamp असलेल्या नावात tar -czf; tar -tzf … || die; rotation साठी ls -1t | tail -n +$((KEEP+1)) | xargs rm; प्रत्येक step वेळेसह log केलेली.

🧪 करून पाहा

bin/backup.sh --dest /tmp/bk --keep 2; bin/backup.sh --dest /tmp/bk --keep 2; bin/backup.sh --dest /tmp/bk --keep 2
ls -1 /tmp/bk                                                     # only 2 remain
mkdir /tmp/bk/.lock; bin/backup.sh --dest /tmp/bk; echo "exit $?"; rmdir /tmp/bk/.lock   # a second run is refused
tar -tzf "$(ls -t /tmp/bk/*.tar.gz | head -1)"                     # what is inside the newest
echo "0 2 * * * PATH=/usr/bin:/bin $PWD/bin/backup.sh --dest /srv/backups >> /var/log/backup.log 2>&1" # what the crontab line looks like
rm -rf /tmp/bk

✅ तपासा — तुम्हाला काय दिसायला हवे

तीन runs, तीन verified ओळी, मग rotated out messages आणि kept 2 backups; lock असलेला run another backup is running छापतो आणि 1 ने exit होतो; archive मध्ये register.csv दिसते.

🏁 तुम्ही आत्ताच काय सिद्ध केले

तुम्ही असा job schedule करू शकता जो एका वेळी एकदाच चालतो, आपला इतिहास मर्यादित ठेवतो, आपले output स्वतः सिद्ध करतो, आणि त्याने काय केले ते सांगतो.

⚠️ नेहमीच्या चुका

तुमच्या shell मध्ये चालणारी पण cron मध्ये fail होणारी cron ओळ: PATH, HOME, relative paths.
lock नाही: एकमेकांवर आलेले दोन runs एकच file बिघडवतात.
log ओळीशिवाय यश. शांतता आणि कधीच-न-चाललेले यात फरक करता येत नाही.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: log rotation, certificate renewal, रात्रीचे reports, cache warmers — ops चे अर्धे काम scheduled scripts असते, आणि त्यांपैकी प्रत्येकाला या चार सवयी लागतात.

⏭️ पुढे

धडा 11 — CI आणि containers मधल्या scripts: मेलरूममधला केअरटेकर, जिथे terminal नाही आणि exit code हेच सर्वस्व आहे.

🔔 Lesson 10 — Scheduling & automation: the bell

📍 You are here: Lesson 10 of 12 · Next: lesson-11-ci-and-containers

📦 What's in this branch

Lessons 01–10. Running a script when nobody is there — and the four habits that keep it from running twice, silently, or into a mess.

bin/backup.sh — the nightly job: tar → verify → rotate, a lock, a log

🧒 Explain like I'm 5

The bell rings at two in the morning and the caretaker runs the backup card. Nobody is watching, so the card must: run only once at a time (a lock on the door), be safe to run again (idempotent — the same result), write down what happened (a log with times), and fail loudly if anything is wrong (strict mode from lesson 08). The bell itself is cron on most machines, a systemd timer on modern Linux, or a schedule in CI.

🗺️ Diagram

flowchart LR
  C["🔔 cron: 0 2 * * *"] --> B["backup.sh"]
  B --> L{"mkdir lock?"} -->|exists| D["die: already running"]
  L -->|ok| T["tar → verify → rotate"] --> U["rmdir lock (trap)"] --> G["log: kept 5"]

❓ What

crontab -e, five fields: min hour day month weekday — 0 2 * * * daily at 02:00, */15 * * * * every 15 minutes. crontab -l lists.
cron's environment is bare: no PATH beyond the basics, no HOME you expect, cwd is /. Use absolute paths, set PATH in the crontab, redirect output to a log or set MAILTO.
Locks: mkdir "$LOCK" || die is atomic; flock on Linux; release in a trap. Idempotent: run it twice, the same state. Retention: keep N.
systemd timers: OnCalendar=daily, logs in journalctl -u, no overlaps, catch-up after downtime. In the cloud: EventBridge, a Kubernetes CronJob.
Verify what you produced: tar -tzf at minimum; a restore drill monthly.

🤔 Why

"The backup ran for months" and "the backup was empty for months" look the same from the outside. Only a log, a verification and an occasional restore tell them apart.

🔧 How (in this repo)

backup.sh: KEEP, DEST, SRC with defaults; mkdir "$LOCK" || die; trap 'rmdir "$LOCK"; log done' EXIT; tar -czf into a timestamped name; tar -tzf … || die; ls -1t | tail -n +$((KEEP+1)) | xargs rm for rotation; every step logged with a time.

🧪 Try it

bin/backup.sh --dest /tmp/bk --keep 2; bin/backup.sh --dest /tmp/bk --keep 2; bin/backup.sh --dest /tmp/bk --keep 2
ls -1 /tmp/bk                                                     # only 2 remain
mkdir /tmp/bk/.lock; bin/backup.sh --dest /tmp/bk; echo "exit $?"; rmdir /tmp/bk/.lock   # a second run is refused
tar -tzf "$(ls -t /tmp/bk/*.tar.gz | head -1)"                     # what is inside the newest
echo "0 2 * * * PATH=/usr/bin:/bin $PWD/bin/backup.sh --dest /srv/backups >> /var/log/backup.log 2>&1" # what the crontab line looks like
rm -rf /tmp/bk

✅ Verify — what you should see

Three runs, three verified lines, then rotated out messages and kept 2 backups; the locked run prints another backup is running and exits 1; the archive lists register.csv.

🏁 What you just proved

You can schedule a job that runs once at a time, keeps its history bounded, proves its own output, and says what it did.

⚠️ Common mistakes

A cron line that works in your shell and fails in cron: PATH, HOME, relative paths.
No lock: two overlapping runs corrupt the same file.
Success with no log line. Silence and never-ran are indistinguishable.

🏭 Why this matters in production: log rotation, certificate renewal, nightly reports, cache warmers — half of ops is scheduled scripts, and every one of them needs these four habits.

⏭️ Next

Lesson 11 — scripts in CI & containers: the caretaker in the mailroom, where there is no terminal and the exit code is everything.

← Previousprocesses jobs Next →ci and containers

This page is the lesson's README from the lesson-10-scheduling branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.