Bài 20: Cron và scheduled jobs
Bài này chi tiết hóa cron và scheduled jobs theo hướng dễ hiểu, có lệnh thực hành, tình huống production, checklist và bài tập.
- Hiểu cron và scheduled jobs dùng để giải quyết vấn đề gì trong production.
- Nắm các lệnh/cấu hình quan trọng.
- Biết quy trình thực hành từng bước trong lab.
- Có checklist kiểm tra trước khi áp dụng production.
Chốt ý nhanh
| Chủ đề | Điểm cần nhớ |
|---|---|
| Cron | Dùng để chạy lệnh định kỳ, rất tiện nhưng cũng rất dễ gây lỗi âm thầm. |
| Điều quan trọng | Biết job chạy lúc nào, chạy bằng user nào, ghi log ở đâu và nếu fail thì ai biết. |
| Production mindset | Job tự động phải được quản như một service nhỏ, không phải “viết xong để đó”. |
1. Bối cảnh thực tế
Cron và scheduled jobs không phải kiến thức lý thuyết riêng lẻ. Trong vận hành production, nó giúp giảm downtime, giảm rủi ro bảo mật và giúp hệ thống dễ khôi phục hơn khi có sự cố.
2. Các khái niệm cần nắm
- Trạng thái hiện tại: trước khi sửa phải biết hệ thống đang chạy thế nào.
- Thay đổi nhỏ: thay đổi từng bước để dễ rollback.
- Log/metric: dùng để xác nhận thay đổi đúng hay sai.
- Rollback: luôn có đường quay lại khi cấu hình lỗi.
3. Lab thực hành
crontab -l crontab -e systemctl status cron || systemctl status crond grep CRON /var/log/syslog | tail || journalctl -u cron --since today # ví dụ cron 0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
Khi thực hành, anh nên ghi lại output trước và sau. Đây là thói quen rất quan trọng của SysAdmin/DevOps.
4. Tình huống thực tế
Backup cần chạy mỗi đêm. Anh tạo cron job, redirect log, test script chạy thủ công trước, kiểm tra timezone và kiểm tra log sau khi cron chạy.
5. Quy trình triển khai an toàn
- Xác định mục tiêu thay đổi.
- Backup file cấu hình hoặc tạo snapshot nếu thay đổi rủi ro.
- Kiểm tra trạng thái hiện tại bằng lệnh phù hợp.
- Thay đổi trên lab/staging trước nếu có.
- Áp dụng production trong khung giờ phù hợp.
- Kiểm tra log, service, port, endpoint sau thay đổi.
- Ghi lại thay đổi và phương án rollback.
6. Lỗi thường gặp
- Làm trực tiếp production mà không backup.
- Sửa nhiều thứ cùng lúc nên không biết lỗi do đâu.
- Không đọc log sau khi reload/restart service.
- Không ghi lại command đã chạy.
7. Checklist
- Đã kiểm tra trạng thái hiện tại.
- Đã backup cấu hình/dữ liệu liên quan.
- Đã test syntax/config nếu có.
- Đã xác nhận service hoạt động sau thay đổi.
- Đã ghi lại thay đổi vào tài liệu vận hành.
8. Bài tập
- Dựng lab nhỏ cho chủ đề này.
- Chạy toàn bộ lệnh kiểm tra.
- Tạo một lỗi nhỏ có kiểm soát và sửa lại.
- Viết checklist 5 bước dùng cho production.
Phần thực hành mở rộng: cron theo góc nhìn vận hành và kiểm soát rủi ro
Nhiều sự cố production đến từ scheduled job chạy trùng, chạy quá lâu, ghi đè dữ liệu hoặc fail mà không ai biết. Vì vậy cron phải được nhìn như một phần của hệ thống, không phải chi tiết phụ.
Lab 1: Xem cron hiện có trên máy
crontab -l
sudo crontab -l
ls -la /etc/cron.daily /etc/cron.hourly /etc/cron.d
systemctl status cron || systemctl status crondMục tiêu là biết toàn cảnh: user cron, system cron và daemon chịu trách nhiệm chạy job.
Lab 2: Tạo một job đơn giản có log
(crontab -l 2>/dev/null; echo '*/5 * * * * date >> /tmp/cron-lab.log 2>&1') | crontab -
tail -f /tmp/cron-lab.logKhi học cron, phải luôn đi kèm output hoặc log, nếu không rất khó biết job có chạy thật hay không.
Lab 3: Mô phỏng script có environment rõ ràng
cat <<'EOF' > /tmp/cron-job.sh
#!/bin/bash
set -euo pipefail
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
echo "$(date) hello cron" >> /tmp/cron-script.log
EOF
chmod +x /tmp/cron-job.sh
/tmp/cron-job.shRất nhiều cron fail chỉ vì biến môi trường khác shell interactive, đặc biệt là PATH.
Lab 4: Tránh chạy chồng job
flock -n /tmp/backup.lock /usr/local/bin/backup.sh
Nếu một job backup mất 20 phút mà cron gọi mỗi 5 phút, anh có thể tạo ra các lần chạy chồng lên nhau và phá hệ thống.
Lab 5: Kiểm tra log cron và kết quả thực thi
sudo journalctl -u cron --since "2 hours ago" --no-pager || sudo journalctl -u crond --since "2 hours ago" --no-pager
sudo grep CRON /var/log/syslog | tail -30Hãy phân biệt log daemon cron và log của chính script được cron gọi.
Tình huống thực tế
Một backup job chạy lúc 02:00 mỗi ngày nhưng vài tuần không tạo file nào vì script lỗi đường dẫn. Vì không có log rõ ràng và không có alert, cả đội chỉ phát hiện khi cần restore. Đây là kiểu lỗi rất thường gặp ngoài đời.
Lỗi phổ biến
- Viết cron không redirect output.
- Dùng relative path trong script.
- Không khóa job chống chạy chồng.
- Không có cơ chế phát hiện job fail.
Kết bài
Nếu bài này chắc, anh sẽ nhìn cron như một hệ thống tự động cần quan sát và kiểm soát, không phải nơi “ném script vào cho chạy”. Từ đây, bài logrotate sẽ nối rất tự nhiên: khi job và service sinh log dài ngày, anh cần biết cách giữ log hữu ích mà không làm đầy disk.
