لاگ‌های crontab: کجا پیداشون کنیم و کرون جاب‌ها رو چطور عیب‌یابی کنیم.

وقتی یه کرون جاب درست کار نمی‌کنه، اولین سؤال همیشه اینه: «اصلاً اجرا شد؟». لاگ‌های خود کرون به این جواب می‌دن؛ خروجی کار شما به سؤال «و چه اتفاقی افتاد؟». این دو جای متفاوتی هستن و خیلی از سیستم‌ها به‌طور پیش‌فرض فقط یکی‌شون رو نگه می‌دارن.

نکته‌های کلیدی

• لاگ کرون ثبت می‌کنه که یه کار شروع شد؛ خروجی کار داخلش نیست.
• روی دبیان و اوبونتو توی /var/log/syslog یا journalctl -u cron بگردید؛ روی خانواده‌ی RHEL توی /var/log/cron یا journalctl -u crond.
• stdout و stderr هر کار رو به فایل لاگ مخصوص خودش بفرستید.
• زمان و کد خروج رو اضافه کنید تا هر خط لاگ کل ماجرا رو بگه.
• لاگ گذشته رو نشون می‌ده؛ مانیتور Heartbeat همین الان می‌گه یه اجرا جا افتاده.

دو نوع لاگ کرون

1. لاگ سرویس کرون؛ هر بار که کرون یه دستور رو شروع می‌کنه یه خط: زمان، کاربر و دستور. ثابت می‌کنه زمان‌بندی اجرا شده.
2. خروجی خود کار؛ هر چیزی که دستور چاپ کرده. کرون این رو ذخیره نمی‌کنه؛ بدون redirect سعی می‌کنه ایمیلش کنه و روی بیشتر سرورها این ایمیل به هیچ‌جا نمی‌رسه.

لاگ سرویس کرون کجاست؟

جستجوهای کاربردی:

grep CRON /var/log/syslog | tail -n 20
journalctl -u cron --since "1 hour ago"
journalctl -u crond --since today | grep backup

یه خط معمولی این‌شکلیه:

Oct 18 03:00:01 web1 CRON[48211]: (deploy) CMD (/opt/app/backup.sh >> /var/log/backup.log 2>&1)

اگه این خط هست، کرون کار خودش رو کرده و مشکل داخل خود کاره. اگه نیست، زمان‌بندی، مالک crontab و اینکه اصلاً سرویس کرون اجرا می‌شه رو بررسی کنید: systemctl status cron (یا crond).

ذخیره‌ی خروجی هر کار

برای هر کاری که براتون مهمه، هر دو جریان خروجی رو redirect کنید:

0 3 * * * /opt/app/backup.sh >> /var/log/app/backup.log 2>&1

• >> به‌جای بازنویسی در هر اجرا، به آخر فایل اضافه می‌کنه.
• 2>&1 خطاها رو هم به همون فایل می‌فرسته؛ بیشتر خرابی‌ها روی stderr هستن.

زمان و کد خروج رو اضافه کنید

لاگی پر از خروجی بدون تاریخ خوندنش سخته. یه wrapper کوچیک درستش می‌کنه:

#!/bin/bash
# /usr/local/bin/cronlog - run a command, prefix its output with timestamps
name="$1"; shift
{
  echo "=== $(date '+%F %T') start $name"
  "$@" 2>&1 | while IFS= read -r line; do echo "$(date '+%F %T') $line"; done
  code=${PIPESTATUS[0]}
  echo "=== $(date '+%F %T') end $name exit=$code"
} >> "/var/log/cron-jobs/$name.log"

0 3 * * * /usr/local/bin/cronlog backup /opt/app/backup.sh

نذارید لاگ‌ها دیسک رو پر کنن

برای لاگ کارهاتون یه قانون logrotate اضافه کنید:

/var/log/cron-jobs/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
}

عیب‌یابی کاری که اجرا نشد

این‌ها رو به ترتیب بررسی کنید:

1. کرون شروعش کرد؟ توی لاگ سرویس دنبال دستور در دقیقه‌ی مورد انتظار بگردید.
2. زمان‌بندی همونیه که فکر می‌کنید؟ پنج فیلد و منطقه‌ی زمانی سرور رو با timedatectl چک کنید.
3. crontab درستیه؟ crontab -l برای کاربر، و /etc/cron.d/ و /etc/crontab برای کارهای سیستمی.
4. دستور توی محیط کرون کار می‌کنه؟ با env -i، یه PATH حداقلی و /bin/sh اجراش کنید.
5. چی چاپ کرد؟ فایل لاگ خود کار رو بخونید.
6. هنوز در حال اجراست؟ pgrep -af backup.sh؛ یه اجرای قبلی گیرکرده به‌علاوه‌ی فایل قفل می‌تونه جلوی همه‌ی اجراهای جدید رو بگیره.

راهنمای ویرایش امن crontab مشکل‌های محیطی پشت بیشتر این خرابی‌ها رو توضیح می‌ده.

از لاگ تا هشدار

لاگ برای بررسی بعد از رخداد عالیه و ساعت ۳ صبح، اگه کسی نخونه، بی‌فایده است. دو چیز اون رو به هشدار زودهنگام تبدیل می‌کنه:

• مانیتورینگ Heartbeat؛ کار در صورت موفقیت یه آدرس رو صدا می‌زنه و اگه دیر بشه هشدار می‌گیرید. مانیتورینگ کرون جاب رو ببینید.
• ارسال لاگ‌ها به یه جای مرکزی؛ فرستادن لاگ کارها به یه پلتفرم لاگ اجازه می‌ده بین سرورها جستجو کنید و روی الگوهای خطا هشدار بذارید.

پرسش‌های پرتکرار

• چرا روی سرورم هیچ لاگ کرونی نیست؟

  +

  نصب‌های مینیمال و کانتینرها معمولاً سرویس syslog ندارن، پس کرون جایی برای نوشتن نداره. اگه systemd هست از journalctl استفاده کنید یا خروجی کارها رو خودتون به فایل بفرستید.

• می‌شه کرون رو مجبور کرد جزئیات بیشتری لاگ کنه؟

  +

  بعضی نسخه‌ها پرچم سطح لاگ دارن (مثلاً cron -L 15 در کرون دبیان). معمولاً ساده‌تره که داخل خود کار لاگ بنویسید.

• چطور خروجی کرون رو بدون تغییر کار ببینم؟

  +

  خروجی‌ای که ذخیره نشده قابل بازیابی نیست. MAILTO رو روی یه آدرس سالم بذارید یا redirect اضافه کنید و منتظر اجرای بعدی بمونید.