کرون جاب در لینوکس و systemd timers؛ زمان‌بندی کارها با مثال

بکاپ شبانه، پاک کردن لاگ‌های قدیمی، تمدید گواهی SSL، اجرای کارهای زمان‌بندی‌شده وردپرس؛ بخش زیادی از نگهداری سرور کارهایی است که باید خودکار و سر وقت اجرا شوند. لینوکس دو ابزار اصلی برای این کار دارد: cron قدیمی و ساده، و systemd timers با امکانات بیشتر. در این راهنما کرون جاب در لینوکس و جایگزین مدرن آن را با مثال‌های کاربردی توضیح می‌دهیم.

cron چیست؟

cron سرویسی است که دستورها را در زمان‌های مشخص اجرا می‌کند. هر کاربر یک جدول زمان‌بندی (crontab) دارد و علاوه بر آن، فایل‌های سیستمی در /etc/crontab و پوشه /etc/cron.d/ وجود دارند. پوشه‌های /etc/cron.daily و مشابه آن هم اسکریپت‌هایی را که داخلشان قرار بگیرد، روزانه یا هفتگی اجرا می‌کنند. اگر با خط فرمان آشنا نیستید، ابتدا دستورات پایه لینوکس را ببینید.

ساختار زمان‌بندی cron

┌───── دقیقه (0-59)
│ ┌───── ساعت (0-23)
│ │ ┌───── روز ماه (1-31)
│ │ │ ┌───── ماه (1-12)
│ │ │ │ ┌───── روز هفته (0-7، 0 و 7 یکشنبه)
│ │ │ │ │
* * * * *  دستور

زمان cron بر اساس منطقه زمانی سرور است؛ آن را با timedatectl بررسی کنید.

ویرایش crontab

crontab -e        # ویرایش جدول کاربر فعلی
crontab -l        # نمایش
sudo crontab -u www-data -e   # ویرایش جدول کاربر دیگر

نمونه یک خط کامل با ثبت خروجی در لاگ:

30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

کارها را با کمترین دسترسی لازم اجرا کنید؛ مثلاً کارهای سایت با کاربر سایت، نه root.

دام‌های رایج cron

• PATH محدود: cron محیط کاملی مثل ترمینال شما ندارد. در دستورها مسیر کامل برنامه‌ها را بنویسید (/usr/bin/php) یا PATH را در بالای crontab تعریف کنید.
• علامت ٪: در crontab کاراکتر % معنای خاص دارد و باید \% نوشته شود؛ مثلاً در date +\%F.
• خروجی گم می‌شود: بدون هدایت خروجی به فایل، خطاها دیده نمی‌شوند.
• اجرای هم‌پوشان: اگر کار طولانی‌تر از فاصله زمان‌بندی شود، دو نسخه همزمان اجرا می‌شوند. با flock جلوگیری کنید:

*/10 * * * * /usr/bin/flock -n /tmp/sync.lock /usr/local/bin/sync.sh

systemd timers

در systemd، هر کار زمان‌بندی‌شده از دو فایل تشکیل می‌شود: یک service که کار را تعریف می‌کند و یک timer که زمان اجرا را.

/etc/systemd/system/site-backup.service:

[Unit]
Description=Nightly site backup

[Service]
Type=oneshot
User=deploy
ExecStart=/usr/local/bin/backup.sh

/etc/systemd/system/site-backup.timer:

[Unit]
Description=Run site backup nightly

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=10min
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now site-backup.timer
systemctl list-timers             # زمان اجرای بعدی همه تایمرها
journalctl -u site-backup.service # لاگ اجراها
sudo systemctl start site-backup.service   # اجرای دستی برای تست

Persistent=true یعنی اگر سرور در زمان اجرا خاموش بوده، پس از روشن شدن کار اجرا شود. یک service از نوع oneshot تا پایان اجرا دوباره شروع نمی‌شود، پس مشکل اجرای هم‌پوشان هم وجود ندارد. با systemd-analyze calendar "Mon *-*-* 03:00" می‌توانید عبارت زمانی را تست کنید.

cron یا systemd timer؟

برای کارهای ساده و سریع cron کافی است؛ برای کارهای مهم مثل بکاپ، systemd timer قابل اعتمادتر و قابل پیگیری‌تر است.

نمونه‌های کاربردی

اجرای WP-Cron وردپرس با cron سیستم (همراه با define('DISABLE_WP_CRON', true); در wp-config.php):

*/5 * * * * cd /var/www/example.com && /usr/local/bin/wp cron event run --due-now --quiet

این کار در فروشگاه‌ها اثر محسوسی دارد؛ توضیح در افزایش سرعت ووکامرس.

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

15 3 * * * /usr/bin/mysqldump --single-transaction appdb | /usr/bin/gzip > /var/backups/db-$(date +\%F).sql.gz

روش‌های کامل‌تر در بکاپ و انتقال دیتابیس.

پاک کردن فایل‌های قدیمی:

0 5 * * * /usr/bin/find /var/backups -type f -mtime +14 -delete

در cPanel هم بخش Cron Jobs همین قالب زمان‌بندی را با محیط گرافیکی ارائه می‌کند.

مطمئن شوید کار واقعاً اجرا شده

خطرناک‌ترین حالت، کار زمان‌بندی‌شده‌ای است که بی‌صدا متوقف شده؛ مثلاً بکاپی که ماه‌ها اجرا نشده. در انتهای کار، به یک مانیتور «Push» یا «Heartbeat» خبر بدهید تا اگر سیگنال در زمان مقرر نرسید، هشدار دریافت کنید:

/usr/local/bin/backup.sh && curl -fsS -m 10 https://status.example.com/api/push/TOKEN > /dev/null

راه‌اندازی این نوع مانیتور در آموزش Uptime Kuma.

سوالات متداول