التقاط المخرجات·MAILTO·قائمة فحص السجلّات
غالبًا ما يتجاوز cron الفشل بصمت. فإن كان التعبير صحيحًا في هذه الأداة ومع ذلك لا تعمل المهمة، فالأرجح أن المشكلة ليست في التعبير بل في بيئة التنفيذ. نرتّب فيما يلي طرق تضييق نطاق السبب بالتسلسل.
احفظ المخرجات في ملف. يرسل cron افتراضيًا المخرج القياسي والخطأ القياسي للمهمة عبر البريد، لكنها تختفي إن لم يكن البريد مُعدًّا. أضف بعد الأمر >> /var/log/myjob.log 2>&1 لتحفظ كلًّا من stdout وstderr في ملف السجل، فتتحقق فورًا مما حدث.
احصل على تنبيهات عبر MAILTO. بوضع MAILTO="you@example.com" في أعلى crontab تُرسَل مخرجات المهمة وأخطاؤها إلى ذلك العنوان. إنها أبسط وسيلة أمان لمنع الفشل الصامت. وعلى العكس، إن لم ترد بريدًا فأفرغها بـ MAILTO="".
راجع سجلّات النظام. في عائلة Debian·Ubuntu استخدم grep CRON /var/log/syslog، وفي بيئة systemd استخدم journalctl -u cron (أو crond) للتحقق مما إذا كان cron قد أطلق المهمة. التمييز المهم هنا أن 'محاولة التشغيل' تختلف عن 'نجاح السكربت'.
وأخيرًا قائمة فحص للأسباب الشائعة. ① هل حددت كل الأوامر والملفات بـ مسار مطلق؟ ② هل صرّحت بـ PATH اللازم في crontab؟ ③ هل يملك السكربت صلاحية التنفيذ (chmod +x)؟ ④ هل وضعت المهمة في crontab المستخدم الصحيح؟ (crontab الجذر root وcrontab المستخدم العادي منفصلان). تحقق من هذه الأربعة، وأعد التحقق من التعبير نفسه بهذا المفسِّر.