ویرایش امن crontab: دستورها، مثال‌ها و اشتباه‌های رایج.

کاری که توی ترمینال بی‌نقص اجرا می‌شه، ممکنه همون لحظه‌ای که کرون اجراش می‌کنه شکست بخوره. بیشتر این خرابی‌ها موقع ویرایش crontab به وجود میان: یه اشتباه تایپی توی فیلدهای زمان، یه مسیر نسبی، متغیری که فقط توی شل خودتون وجود داره، یا اصلاً ویرایش crontab یه کاربر دیگه.

این راهنما نشون می‌ده crontab رو چطور امن ویرایش کنید، چرا کارها بعد از ویرایش از کار می‌افتن، و چطور مطمئن بشید تغییرتون واقعاً کار می‌کنه، نه اینکه فقط امیدوار باشید.

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

• همیشه با crontab -e ویرایش کنید؛ این دستور فایل رو قبل از نصب بررسی می‌کنه.
• قبل از هر تغییر، با crontab -l از جدول فعلی بکاپ بگیرید.
• محیط اجرای کرون خیلی کوچیکه: مسیر کامل بنویسید و PATH و SHELL رو خودتون تنظیم کنید.
• خروجی هر کار رو توی یه فایل لاگ بریزید، وگرنه خطاها بی‌ردپا گم می‌شن.
• crontabی که درست نصب شده هم ممکنه هیچ‌وقت اجرا نشه؛ اجرای اول رو زیر نظر بگیرید یا از مانیتورینگ Heartbeat استفاده کنید.

«ویرایش crontab» دقیقاً یعنی چی؟

crontab (جدول کرون) فهرستی از دستورهای زمان‌بندی‌شده‌ی هر کاربره. هر خط یه زمان‌بندی رو به یه دستور وصل می‌کنه و سرویس کرون جدول‌های نصب‌شده رو می‌خونه و دستورها رو سر وقت اجرا می‌کنه.

دو راه برای تغییرش هست:

• crontab -e یه نسخه‌ی موقت از جدول رو توی ادیتور باز می‌کنه. وقتی ذخیره کنید و بیرون بیاید، ابزار crontab سینتکس رو چک می‌کنه و نسخه‌ی جدید رو نصب می‌کنه.
• ویرایش مستقیم فایل‌های spool (مثلاً زیر /var/spool/cron/) این بررسی رو دور می‌زنه، ممکنه مالکیت یا دسترسی فایل رو خراب کنه و ساده‌ترین راه برای اینه که کرون بی‌صدا جدول رو نادیده بگیره.

برای crontab کاربرها از crontab -e استفاده کنید. کارهای سراسری سیستم جاشون توی /etc/crontab یا /etc/cron.d/ هست که با دسترسی root و یه ادیتور معمولی ویرایش می‌شن؛ حواستون باشه این فایل‌ها توی هر خط یه فیلد اضافه برای کاربر دارن.

یه فرق مهم هم بین ویرایش و *جایگزین کردن* هست: crontab jobs.txt کل جدول رو با محتوای یه فایل عوض می‌کنه. برای اتوماسیون عالیه، ولی اگه دستی و توی حساب اشتباه تایپ بشه خطرناکه.

انتخاب ادیتوری که crontab باز می‌کنه

crontab -e ادیتور اختصاصی نداره. اول متغیر VISUAL، بعد EDITOR رو نگاه می‌کنه و اگه هیچ‌کدوم نبود سراغ پیش‌فرض سیستم می‌ره (معمولاً vi، گاهی nano). ببینید الان چی تنظیم شده:

echo "VISUAL=$VISUAL EDITOR=$EDITOR"

انتخاب ادیتور فقط برای همین بار

EDITOR=nano crontab -e

دائمی کردن انتخاب

متغیر رو به فایل شروع شل‌تون اضافه کنید (~/.bashrc برای Bash و ~/.zshrc برای Zsh) و یه شل جدید باز کنید:

echo 'export EDITOR=nano' >> ~/.bashrc

دبیان و اوبونتو

روی سیستم‌های مبتنی بر دبیان، دستور select-editor انتخابتون رو توی ~/.selected_editor ذخیره می‌کنه و crontab -e از اون به بعد ازش استفاده می‌کنه.

سرورهای مینیمال و کانتینرها

ایمیج‌های سبک معمولاً nano یا حتی vi ندارن. یا یکی نصب کنید، یا فایل رو جای دیگه بسازید و با crontab file نصبش کنید؛ فقط قبلش از جدول قبلی یه نسخه نگه دارید.

سینتکس crontab در دو دقیقه

هر خط کار، پنج فیلد زمان داره و بعدش دستور میاد:

# ┌ دقیقه (0-59)
# │ ┌ ساعت (0-23)
# │ │ ┌ روز ماه (1-31)
# │ │ │ ┌ ماه (1-12)
# │ │ │ │ ┌ روز هفته (0-7، صفر و هفت یعنی یکشنبه)
# │ │ │ │ │
  30 2 * * * /usr/local/bin/backup.sh

عملگرهایی که لازم دارید

تله‌ی روز ماه و روز هفته

وقتی هر دو فیلد روز محدود شده باشن، کرون کار رو وقتی اجرا می‌کنه که یکی از اون‌ها برقرار باشه، نه هر دو. 0 0 1 * 1 هم روز اول هر ماه اجرا می‌شه *و* هم هر دوشنبه.

عبارت‌های ویژه

بیشتر نسخه‌های کرون میان‌برهایی مثل @reboot، @hourly، @daily، @weekly و @monthly رو قبول می‌کنن. خوندنشون راحت‌تره، ولی قبل از استفاده مطمئن بشید کرون شما پشتیبانی‌شون می‌کنه.

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

یه روال امن برای ویرایش

۱. از جدول فعلی بکاپ بگیرید

crontab -l > ~/crontab-backup-$(date +%F).txt

اگه چیزی خراب شد، crontab ~/crontab-backup-2026-10-18.txt نسخه‌ی قبلی رو برمی‌گردونه.

۲. دستور رو بیرون از کرون امتحان کنید

دقیقاً همون‌طور اجراش کنید که کرون اجرا می‌کنه: با مسیر کامل، از یه پوشه‌ی بی‌طرف و ترجیحاً با محیط خالی.

cd / && env -i HOME="$HOME" SHELL=/bin/sh PATH=/usr/bin:/bin /usr/local/bin/backup.sh

اگه اینجا شکست بخوره، زیر کرون هم شکست می‌خوره.

۳. ویرایش کنید، ذخیره کنید و نتیجه رو بخونید

بعد از ذخیره، crontab پیام installing new crontab رو نشون می‌ده. اگه خطا گزارش کرد، پیشنهاد می‌ده دوباره ادیتور رو باز کنه؛ قبول کنید و به‌جای دور ریختن تغییرات، همون خط رو درست کنید. بعد جدول رو لیست کنید تا ببینید واقعاً چی نصب شده:

crontab -l

۴. اجرای اول رو زیر نظر بگیرید

یه اجرای نزدیک (مثلاً دو دقیقه بعد) زمان‌بندی کنید، توی لاگ ببینید اجرا شده، بعد زمان‌بندی واقعی رو بذارید.

اشتباه‌های رایج و راه حلشون

خطای «bad minute» یا «errors in crontab file»

یکی از فیلدهای زمان مقدار غیرممکن داره (دقیقه‌ی 60، ماه 13)، یه فیلد جا افتاده یا یه کاراکتر اضافه وارد شده. پیام خطا شماره‌ی خط رو می‌گه؛ وقتی crontab پیشنهاد ویرایش دوباره داد، درستش کنید.

خط آخر هیچ‌وقت اجرا نمی‌شه

خیلی از نسخه‌های کرون خط آخری رو که با «خط جدید» تموم نشه نادیده می‌گیرن. آخر فایل یه خط خالی بذارید.

علامت درصد دستور رو نصفه می‌کنه

توی crontab، % بدون escape دستور رو تموم می‌کنه و بقیه‌اش رو ورودی استاندارد حساب می‌کنه. date +%F داخل یه کار باید به شکل date +\%F نوشته بشه.

ویرایش جدول کاربر اشتباه

sudo crontab -e جدول root رو ویرایش می‌کنه، نه جدول شما رو. اون‌وقت کارهایی که به فایل‌ها، کلیدها یا دسترسی‌های شما نیاز دارن با کاربر اشتباه اجرا می‌شن. وقتی واقعاً منظورتون حساب دیگه‌ایه از crontab -u name -e استفاده کنید و با crontab -u name -l چک کنید.

اجازه‌ی استفاده از crontab ندارید

اگه فایل /etc/cron.allow وجود داشته باشه، فقط کاربرهای داخلش می‌تونن crontab داشته باشن؛ وگرنه هر کسی که توی /etc/cron.deny نباشه اجازه داره. پیام «you are not allowed» یعنی کاربر توی یکی از این فهرست‌ها نیست.

چرا کارها بعد از ویرایش از کار می‌افتن؟

محیط کرون تقریباً خالیه

کرون فایل .bashrc یا .profile شما رو نمی‌خونه. PATH معمولاً فقط /usr/bin:/bin هست، SHELL برابر /bin/sh هست و متغیرهایی که توی ترمینال export کردید اونجا وجود ندارن. دستورهایی که توی /usr/local/bin، یه virtualenv یا یه version manager هستن، «پیدا نمی‌شن».

مسیرهای نسبی

کارها از پوشه‌ی خونه‌ی کاربر شروع می‌شن. ./run.sh یا python script.py توی ترمینال کار می‌کنه چون اتفاقاً توی پوشه‌ی درست هستید؛ زیر کرون نه. هم برای برنامه و هم برای هر فایلی که باهاش کار می‌کنه مسیر کامل بنویسید.

sh همون bash نیست

آرایه‌ها، [[ ]]، source و بقیه‌ی امکانات Bash زیر /bin/sh شکست می‌خورن. بالای crontab بنویسید SHELL=/bin/bash، یا کار رو با /bin/bash /path/script.sh شروع کنید.

خروجی به هیچ‌جا نمی‌ره

بدون redirect، کرون سعی می‌کنه خروجی رو برای کاربر ایمیل کنه؛ روی بیشتر سرورها ایمیلی تنظیم نشده، پس خطاها گم می‌شن. هر دو جریان خروجی رو به فایل بفرستید:

*/10 * * * * /opt/app/sync.sh >> /var/log/app-sync.log 2>&1

تنظیم متغیرهای محیطی در crontab

خط‌های متغیر بالای کارهایی میان که بهشون نیاز دارن و روی همه‌ی خط‌های پایینی اثر می‌ذارن:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=""
APP_ENV=production

0 3 * * * /opt/app/bin/nightly-report >> /var/log/nightly-report.log 2>&1

کرون متغیرها رو توی این مقداردهی‌ها باز نمی‌کنه؛ PATH=$PATH:/opt/bin دقیقاً همین متن رو ذخیره می‌کنه. مقدار کامل رو بنویسید. وقتی یه کار به بیشتر از دو سه متغیر نیاز داشت، تنظیماتش رو ببرید توی یه اسکریپت wrapper و خط crontab رو کوتاه نگه دارید.

ویرایش crontab با اسکریپت

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

جایگزینی از یه فایل نسخه‌دار

crontab /srv/deploy/app.crontab

فایل توی مخزن کد، تنها مرجع درست می‌شه و هر تغییر مثل کد بازبینی می‌شه.

اضافه کردن یه خط بدون از دست دادن بقیه

( crontab -l 2>/dev/null | grep -v 'nightly-report' ; echo '0 3 * * * /opt/app/bin/nightly-report' ) | crontab -

grep -v اول نسخه‌ی قدیمی همون کار رو حذف می‌کنه، پس اگه اسکریپت دو بار اجرا بشه کار تکراری ساخته نمی‌شه.

جلوگیری از اجرای هم‌زمان

کاری که گاهی طولانی‌تر از فاصله‌ی اجراش طول می‌کشه، ممکنه هم‌زمان دو بار اجرا بشه. flock فقط اجازه‌ی اجرای یه نسخه رو می‌ده:

*/5 * * * * flock -n /tmp/sync.lock /opt/app/sync.sh >> /var/log/app-sync.log 2>&1

از کجا بفهمیم کار واقعاً اجرا می‌شه؟

نصب شدن crontab فقط ثابت می‌کنه زمان‌بندی پذیرفته شده. چیزی درباره‌ی اینکه کار شروع شد، تموم شد یا کارش رو درست انجام داد نمی‌گه. لاگ‌ها بعد از اتفاق کمک می‌کنن، ولی هیچ‌کس ساعت ۳ صبح لاگ نمی‌خونه.

مانیتورینگ Heartbeat این شکاف رو پر می‌کنه: کار بعد از تموم شدن یه آدرس اختصاصی رو صدا می‌زنه و اگه این تماس سر وقت نرسه، هشدار می‌گیرید.

0 3 * * * /opt/app/backup.sh && curl -fsS -m 10 https://YOUR-HEARTBEAT-URL > /dev/null

&& یعنی پینگ فقط وقتی فرستاده می‌شه که بکاپ موفق بوده؛ پس هم اجرای ناموفق و هم اجرایی که اصلاً شروع نشده هشدار می‌ده. مانیتورینگ کرون جاب در noc724 همین‌طور کار می‌کنه و هشدار رو با پیامک، تلگرام یا بله می‌فرسته.

جمع‌بندی

ویرایش امن crontab خلاصه می‌شه به یه روال کوتاه: بکاپ بگیرید، دستور رو همون‌طور که کرون اجرا می‌کنه امتحان کنید، با crontab -e ویرایش کنید، چیزی رو که نصب شده بخونید و اجرای اول رو ببینید. بیشتر مشکل‌های «قبل از ویرایش کار می‌کرد» مشکل محیط اجرا هستن (مسیرها، شل و متغیرها)، نه خود کرون. و چون کرون هیچ‌وقت خبر نمی‌ده که یه کار بی‌صدا متوقف شده، برای هر کار مهم یه چک Heartbeat بذارید.

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

• چطور crontab رو برای ویرایش باز کنم؟

  +

  دستور crontab -e رو اجرا کنید. جدول کاربر شما رو توی ادیتوری که VISUAL یا EDITOR تعیین کرده باز می‌کنه و بعد از ذخیره نصبش می‌کنه.

• چطور ببینم چه کارهایی نصب شده؟

  +

  crontab -l جدول شما رو نشون می‌ده و sudo crontab -u name -l جدول یه کاربر دیگه رو. کارهای سیستمی توی /etc/crontab و /etc/cron.d/ هستن.

• بعد از ویرایش باید کرون رو ری‌استارت کنم؟

  +

  نه. crontab -e خودش به سرویس خبر می‌ده و جدول جدید ظرف یه دقیقه خونده می‌شه. فایل‌های /etc/cron.d/ هم روی بیشتر سیستم‌ها خودکار دوباره خونده می‌شن.

• چطور همه‌ی کارهای کرونم رو پاک کنم؟

  +

  crontab -r بدون هیچ سؤالی کل جدول رو پاک می‌کنه. اول با crontab -l بکاپ بگیرید؛ و حواستون باشه -r روی کیبورد چقدر به -e نزدیکه.

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

  +

  معمولاً به خاطر محیط اجرا: PATH کوتاه، /bin/sh به‌جای Bash، متغیرهای جاافتاده یا مسیرهای نسبی. مسیر کامل بنویسید و متغیرها رو توی crontab یا یه اسکریپت wrapper تنظیم کنید.