يُعد Zima Cron إحدى أدوات الجدولة القليلة المنشورة مباشرةً لـ ZimaOS بدلًا من إضافتها كحاوية Docker عامة. ويوضح البرنامج التعليمي من IceWhale في يناير 2026 كيفية تثبيته باستخدام zpkg، وأنشئ مهام تستند إلى فترات زمنية أو تعبيرات cron، وتحقق من التنفيذ عبر السجلات، واستخدمها للبرامج النصية أو النسخ الاحتياطية أو الصيانة الدورية.
يتضمن موضوع المصدر أيضًا قصة ثانية مهمة اختُصرت أكثر من اللازم في النسخة الموجزة السابقة من هذه المقالة: كانت الاستمرارية بعد إعادة التشغيل غير متسقة بين الأنظمة. فقد بعض مستخدمي ZimaOS 1.5.3 و1.5.4 جميع المهام المجدولة أو وجدوا zima-cron.service غير نشط بعد إعادة التشغيل، بينما أظهرت بيئة اختبار نظيفة بقاء المهام بعد إعادة التشغيل. والاستنتاج الصحيح هو إذن «مجدول رسمي مع تحفظ يتعلق باستمرارية البيانات حسب الإصدار»، وليس ببساطة «ثبّته وانس أمره».
ثبّت Zima Cron باستخدام مدير الحزم الرسمي zpkg
يبدأ البرنامج التعليمي من IceWhale من طرفية ZimaOS ويستخدم:
zpkg install zima_cronيذكر المصدر صراحةً أنه لا يلزم إجراء إعادة تشغيل بعد التثبيت. وبعد ذلك، ينبغي أن يظهر Zima Cron في قائمة التطبيقات ضمن واجهة الويب الخاصة بـ ZimaOS.
zpkg.أنشئ مهمة اختبار آمنة قبل جدولة أي شيء مهم
يستخدم البرنامج التعليمي الرسمي عن قصد مهمة تسجيل آمنة مدتها دقيقة واحدة بدلًا من أمر صيانة مدمّر. وهذا نمط جيد لأي أداة جدولة: تحقّق من تنفيذ الواجهة الخلفية، ومن تفسير الجدول بشكل صحيح، ومن كتابة الناتج في المكان المتوقع قبل أتمتة النسخ الاحتياطية أو إعادة تشغيل الخدمات.
يضيف المثال الرسمي طابعًا زمنيًا إلى ملف سجل:
bash -c 'echo "$(date "+%Y-%m-%d %H:%M:%S") zima cron works" >> /DATA/zima_cron_test.log'نظرًا لأن هذا الأمر يضيف النص فقط، فهو مناسب للتحقق من الجدولة دون تعديل حالة التطبيق.
استخدم الجدولة الفترية للتكرار البسيط
يكون الجدول الزمني الفتري مناسبًا عندما لا يهم الوقت المحدد على مدار الساعة. وتشمل الأمثلة فحصًا صحيًا خفيفًا كل بضع دقائق أو مهمة تنظيف كل عدة ساعات.
بالنسبة إلى المهام المهمة، تذكّر أن «كل 24 ساعة» لا تعادل دائمًا «كل يوم عند الساعة 4:00 صباحًا»، لا سيما بعد إعادة تشغيل الخدمات. استخدم تعبير cron عندما يكون وقت محدد من اليوم مهمًا.
استخدم تعبيرات cron القياسية للجداول المعتمدة على التقويم
يعرض البرنامج التعليمي الرسمي أيضًا صيغة cron القياسية. على سبيل المثال:
*/5 * * * *يعمل كل خمس دقائق. ويمكن لتعبير cron عادي أن يمثل جداول يومية أو أسبوعية أو شهرية أو خاصة بأيام معينة من الأسبوع، ما يجعل Zima Cron أكثر مرونة من مجرد فاصل زمني ثابت.
قبل نشر تعبير معقد، اختبره باستخدام أمر تسجيل غير ضار وتحقق من نجاح تنفيذه مرتين على الأقل.
تحقق من التنفيذ في Zima Cron وفي ملف الإخراج
ينبغي أن يتحقق الاختبار الكامل من كلٍّ من واجهة جدولة المهام والتأثير الجانبي المتوقع—مثل ظهور أسطر جديدة في /DATA/zima_cron_test.log. يلتقط ذلك الحالات التي تكون فيها مهمة موجودة في واجهة المستخدم، لكن أمرها يفشل بسبب الأذونات أو المسارات أو علامات الاقتباس أو الملفات التنفيذية المفقودة.
تتطلب جدولة إعادة تشغيل التطبيقات تحديد حدود الأمر المناسبة
سأل أحد المستخدمين عن كيفية إعادة تشغيل Home Assistant يوميًا عند الساعة 4 صباحًا. لم يتلقَّ الموضوع أمرًا رسميًا من IceWhale لإدارة تطبيق مثبت بعينه، لذا ينبغي ألا تختلق هذه المقالة أمرًا. يمكن لـ Zima Cron تشغيل أوامر الصدفة، لكن الأمر الدقيق الخاص بأي تطبيق يعتمد على كيفية إدارة ذلك التطبيق بواسطة ZimaOS، وعلى مدى أمان إعادة تشغيله خارج طبقة إدارة التطبيقات.
استخدم أداة الجدولة للأوامر التي تحققت منها يدويًا مسبقًا. لا تجعل إعادة تشغيل تطبيق إنتاجي الاختبار الأول.
المحاذير الرئيسية: فقد بعض المستخدمين مهامهم بعد إعادة التشغيل
في 26 يناير، أبلغ مستخدم لـ ZimaOS 1.5.3 عن اختفاء المهام المحفوظة بعد إعادة التشغيل. وردّ 777-Spider بأن IceWhale سيتحقق من المشكلة. ثم أعاد مستخدمون إضافيون إنتاج سلوك مشابه، ما جعلها مشكلة موثوقية حقيقية وليست مجرد سوء فهم عابر.
لاحقًا، أفادت التقارير بأن التثبيت النظيف الخاضع للتحكم تصرف بشكل صحيح: zima-cron.service ظل نشطًا، وبقيت المهام ظاهرة بعد إعادة التشغيل، واستمر التسجيل. بدا ذلك واعدًا، لكنه لم يكن نهاية القصة.
أنتج الاختبار النظيف والاختبار في العالم الحقيقي نتائج مختلفة
ثبّت مشارك آخر لاحقًا Zima Cron عبر zpkgوأنشأ مهمة، ثم أفاد بعد إعادة التشغيل بأن المهام اختفت وأنه تعذّر إنشاء مهام جديدة. وكانت حالة خدمته تعرض:
zima-cron.service
محمّلة: محمّلة
نشطة: غير نشطة (متوقفة)تعارض ذلك مباشرةً مع نتيجة النظام النظيف التي بدأت فيها الخدمة تلقائيًا واستمرت المهام. والتفسير الصحيح هو أن مشكلات الاستمرارية كانت تعتمد على البيئة أو الإصدار، ولم تُحل بشكل قاطع لكل مستخدم.
ما الذي ينبغي التحقق منه بعد إعادة التشغيل
أوصت سلسلة النقاش بالتحقق من استمرار نشاط الخدمة ومن إجراء التثبيت بصورة صحيحة عبر zpkg. بالنسبة إلى عملية نشر مهمة، ينبغي أن تشمل الحد الأدنى من ضمان الجودة بعد إعادة التشغيل ما يلي:
- أعِد تشغيل جهاز ZimaOS عمدًا.
- أكّد أن Zima Cron لا يزال ظاهرًا.
- أكّد أن المهمة المحفوظة لا تزال ظاهرة.
- أكّد أن الخدمة الخلفية نشطة.
- انتظر حتى التنفيذ المجدول التالي.
- تحقق من المخرجات الفعلية للمهمة، وليس من حالة واجهة المستخدم فقط.
أُبلغ عن مشكلة الاستمرارية علنًا أيضًا
يحتوي مشروع Zima Cron على بلاغ عام يصف فقدان المهام وتعطّل الخدمة بعد إعادة التشغيل. قبل الاعتماد عليه للصيانة غير المراقَبة، تحقق من الحالة الحالية لبلاغ استمرار المهام بعد إعادة التشغيل.
لا تجعل مُجدوِلًا غير مُختبَر مُشغّل النسخ الاحتياطي الوحيد لديك
يُعد Zima Cron مفيدًا للأتمتة، لكن اختفاء نسخة احتياطية مجدولة بصمت بعد إعادة التشغيل أسوأ من نسخة احتياطية يدوية تعرف أنها لم تُنفَّذ. إذا كانت المهمة مهمة، فاجمع بين اختبار المُجدوِل وعمليات تحقق مستقلة من حالة النسخ الاحتياطي واختبار الاستعادة.
الأسئلة الشائعة حول Zima Cron
هل أمر تثبيت Zima Cron رسمي؟
نعم. zpkg install zima_cron نشره 777-Spider في البرنامج التعليمي لـ IceWhale.
هل يمكنه استخدام تعبيرات cron العادية؟
نعم. يدعم البرنامج التعليمي الرسمي جداول الفواصل الزمنية وتعبيرات cron القياسية.
هل تنجو المهام بالتأكيد من إعادة التشغيل؟
لا يمكن تقديم ضمان شامل استنادًا إلى سلسلة النقاش المصدرية. نجحت بعض الاختبارات النظيفة، بينما فقدت أنظمة أخرى تعمل بالإصدار 1.5.x المهام مرارًا أو تركت الخدمة غير نشطة.
ما الذي ينبغي أن أفعله قبل الوثوق به لتنفيذ مهمة مهمة؟
أجرِ اختبار إعادة تشغيل فعليًا، وتحقق من بقاء المهمة معرّفة، وأكّد أن الأمر يُنفَّذ بنجاح بعد ذلك.
