cron مقابل مؤقتات systemd: cron يشغّل سطوراً، والمؤقتات تشغّل وحدات

الساعتان

المهمة نفسها — نسخ احتياطي ليلي في 03:30 — على الساعتين، وما يخلف كل واحدة وراءها:

30 3 * * * /usr/local/bin/backup.sh

# foo.timer
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
# foo.service — the job itself

حكم الجدولة: خمسة حقول cron هي الـ incumbent المكثّف؛ OnCalendar أطول لفظاً لكنه أعلى تعبيراً قطعاً — Mon..Fri 09..17:00:00 من سطر واحد، وRandomizedDelaySec يمنع ألف جهاز من مطرقة خادم واحد

هذه الساعتان تحدّدان التوقيت من أوامر السجل ذاتها — لا تقدران على قراءة journal جهازك؛ أين journal فعلياً: القسمان 04 و05.

الفجوات العملية

• التسجيل : المؤقتات تسجل stdout/stderr في journal لكل وحدة؛ cron في أحسن الأحوال يرسل بريداً للمستخدم المحلي.
• التشغيلات الفائتة : مؤقت بـ Persistent=true يجري مرة عند الإقلاع إذا فاتته جدولته؛ cron يتخطاها ببساطة.
• الاعتماديات : المؤقتات تقدر تنتظر network-online.target أو نقاط التحميل؛ cron يوجب عليك بناء منطق إعادة المحاولة بيديك داخل السكربت.
• الصياغة : cron سطر واحد؛ والمؤقت ملفان. هذه هي تكلفة الانتقال كاملة.
• خيار monotonic: OnBootSec=15min — تغيّرات ساعة الحائط لا تربكه.

04اختبر مؤقتاً دون انتظار

ثلاثة أوامر تجيب عن كل شيء — اعرض ما هو مبرمج ومتى سيشتعل في المرة القادمة، شغّل المهمة بيديك كما سيشغلها المؤقت تماماً، ثم اقرأ سجلاته:

systemctl list-timers --all                 # every timer, next + last run
sudo systemctl start backup.service         # fire the job now, same unit as the timer
journalctl -u backup.service -f             # watch its output live

انتبه للانفصال: systemctl start backup.timer تسلح الجدولة؛ service هي المهمة. إذا list-timers أظهر مؤقتك، systemctl status backup.service أخضر، والسجل يظهر مخرجك — فالسلسلة كلها تعمل.

verify: systemctl list-timers --all → مؤقتك، آخر + تشغيل قادم مُسرَدان

05شغّل مهمة cron يدوياً

مهام cron تعمل ببيئة مجرّدة، ولهذا فـ «يعمل في شلّي، يفشل في cron» جنس قائم بذاته من الباغات. لإعادة إنتاج cron بصدق، شغّل الأمر عبر sh بالبيئة التي سيستخدمها cron:

crontab -l                                  # confirm the exact line
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # did cron even fire it? (Debian/Ubuntu)
journalctl -u cron -n 20                    # same, on systemd distros

ذلك الـ env -i سطراً هو الاختبار اليدوي الأمين: بيئة عارية مع افتراضي cron وهو PATH. كلاسيكيتا cron الاثنتان — الـ PATH العارية، والـ % غير المقتبسة (يعتبرها cron فاصلة سطر) — كلتاهما تظهران فوراً في هذا الاختبار.

verify: journalctl -u cron -n 20 → سطر CRON لأمرك

«مؤقتي لا يشتعل»

المؤقت الذي يبدي ميتاً هي عادةً خدمته تفشل فوراً. أربعة أسباب، بترتيب الفحص:

1. اسم الخدمة واسم المؤقت غير متطابقين. foo.timer تُشعل foo.service — خطأ مطبعي أو وحدة أُعيدت تسميتها، والمؤقت «يشتغل» في الفراغ. systemctl cat foo.timer يظهر بدقة ما يستهدفه.
2. عُدّل لكن لم يُعاد تحميله. بعد تبديل ملف وحدة: sudo systemctl daemon-reload && sudo systemctl restart foo.timer. بغير ذلك جدولتك الجديدة ليست حية.
3. أمر الحالة خاطئ. systemctl status foo.timer يظهر دائماً active حتى وهو ساكن — اقرأ list-timers بدلاً منه.
4. الخدمة التي يُشعلها تفشل فوراً. journalctl -u foo.service --since -1h يُظهر الانهيار الذي list-timers يحجبه.

verify: journalctl -u foo.service --since -1h → الانهيار الذي يحجبه list-timers

جدول القرار

قواعد الإبهام : تسليم مهمة على جهازك ذي systemd → مؤقت. تذكير شخصي سريع أو صندوق لم تبنيه → cron. أي ذو اعتماديات أو إعادات محاولة أو حاجة لمعرفة هل اشتغل فعلاً → مؤقت، دائماً. النمط الكلاسيكي — نسخ احتياطي ليلي بـ rsync تحت مؤقت مع Persistent=true — يضمن حدوث النسخ حتى لو كانت الآلة نائمة في الدقيقة المحددة، وهو ما لا يقدمه cron إطلاقاً.

نهاية الساعتين · لم يُجلب شيء · كل شيء محلي