لماذا تتراكم مهام systemd Timer؟ دليل منع تداخل التشغيل وضياع نتائج الوظائف

تراكم وظائف المجدول من أخطر الأعطال الصامتة: تبدأ بوظيفة تفوت موعدها، ثم تنمو إلى عشرات عمليات تستهلك الذاكرة وقد توقف موقعًا كاملًا. هذا الدليل يبني نموذجًا عمليًا للتحكم في systemd Timer والعمليات الفرعية وإعادة المحاولة وحجز حالة الأعمال.

المشكلة ليست في المؤقت وحده

المؤقت يقرر وقت التشغيل، لكنه لا يضمن أن المهمة منتهية ولا أن العمليات التي أنشأتها توقفت. إذا نفذت وظيفة كل ربع ساعة واستغرقت ثلاثين دقيقة، فقد تحاول الدورة التالية العمل بالتزامن، أو قد ترفض الوحدة نفسها بدء تشغيل جديد بينما تستمر عمليات فرعية منفصلة. الفرق مهم؛ قفل مستوى الخدمة ليس دائمًا قفل مستوى البرنامج، ولا يضمن انتهاء وحدة oneshot توقف خدمات transient أنشأتها. لذلك تبدأ المراجعة بتتبع العملية الأم والأبناء وطريقة إطلاقهم، وليس بملاحظة وجود ملف timer فقط.

وثّق معيار اكتمال الوظيفة قبل الإصلاح. قد يعلن البرنامج exit 0 بعد إرسال طلب خارجي بينما لا تكون العملية التجارية قد اكتملت. وقد يخرج بخطأ بعد إنشاء مقال ثم تفشل خطوة حفظ معرفه، فتؤدي إعادة المحاولة إلى تكرار المقال. اجعل لكل عمل معرفًا ثابتًا ونتيجة نهائية قابلة للاستعلام، مع حالات queued و running و succeeded و retryable_error و failed بدل حقل نجاح مبهم.

الفرق بين OnCalendar و OnUnitInactiveSec

OnCalendar يربط التشغيل بوقت تقويمي مثل كل خمس عشرة دقيقة. أما OnUnitInactiveSec فيرتبط بالمدة منذ انتهاء آخر تشغيل لوحدة معينة، فيوفر فاصل راحة بعد كل دورة بدل الالتزام بتوقيت الساعة. اختيار أحدهما يعتمد على الهدف: جمع بيانات في مواعيد ثابتة أم عمل خلفي لا تريد إطلاقه قبل انتهاء السابق. إعداد Persistent مع مؤقت تقويمي قد يعوض تشغيلًا فائتًا عند إعادة تفعيل المؤقت؛ وهو مفيد لبعض الجداول، لكنه قد ينشئ دفعة غير مرغوبة بعد توقف طويل إن لم تضع حارسًا للحمل.

لا تستنتج من جدول next/last أن الأعمال نُفذت بنجاح. راجع systemctl status و journalctl -u للخدمة وسجل النتائج الفعلي. كما أن AccuracySec يجعل التنفيذ ضمن نافذة زمنية بدلاً من الالتزام بالثانية المحددة، لذلك لا تعتمد عليه لتحقيق مسافة نشر دقيقة بين مقالتين؛ احسب publishAt داخل نظام النشر نفسه. المؤقت مسؤول عن إطلاق دورة العمل، بينما الجدول التحريري هو المرجع الفعلي لمواعيد ظهور المحتوى.

القفل الفعلي باستخدام flock

القفل يمنع برنامجين من تعديل نفس الطابور في وقت واحد. استخدم flock على ملف ثابت في موقع معروف، واجعل الحصول على القفل غير حاجب حين لا ترغب في الانتظار؛ إذا وجد تشغيل آخر، تسجل الحالة already_running وتخرج دون إنشاء مهمة ثانية. الأهم أن يبقى وصف الملف مفتوحًا طوال وقت العمل، لا لحظة اختيار المقال فقط. ويجب أن تستخدم كل مسارات الإطلاق القفل نفسه، سواء جاءت من timer أو أمر يدوي أو مهمة صيانة.

القفل لا يعالج العمليات التي انفصلت عن الأب بشكل مستقل. إذا أطلق العامل systemd-run، فإن الوحدة العابرة قد تظل تعمل بعد نهاية البرنامج الذي يملك القفل. في هذه الحالة تتبّع وحدة العمل الفعلية واحصر عددها وضمن حدودًا لها، أو غيّر طريقة إدارة العملية بحيث تظل دورة حياتها مرتبطة بالأب. لا تعتبر اختفاء ملف القفل أو PID دليلًا كافيًا لانتهاء كل الأبناء.

حدود الوقت وأنواع الخدمات

في وحدة Type=oneshot يعتبر TimeoutStartSec حدًا لتشغيل أوامر البدء، بينما RuntimeMaxSec ليس بديلًا عامًا له لأنه لا ينطبق على oneshot بالطريقة نفسها التي ينطبق بها على خدمات طويلة المدى. أما وحدة transient التي تشغّل عملية مستمرة فقد تحتاج RuntimeMaxSec وحدودًا إضافية للموارد. يجب اختبار سلوك الإنهاء الفعلي بمهام وهمية تتجاوز الحدود، ومراجعة وحدات run-*.service الناتجة عن الإطلاق إذا استعملت systemd-run.

حد الذاكرة MemoryMax و CPUQuota يحميان المضيف من المهمة الواحدة، لكن استخدام عشرات الوحدات ذات حدود مستقلة قد يستهلك إجمالي موارد كبيرًا. استخدم حد تزامن على مستوى المنظومة بالإضافة إلى حد كل مهمة. عند التوقف أو انتهاء المهلة، احفظ سبب التعطل وحالة المحتوى الجاري ثم أعد تشغيله من نقطة آمنة. لا تجعل الأداة تعتبر العملية ناجحة لمجرد أنها توقفت قبل الموعد.

تصميم طابور يمنع التكرار

ابدأ بقائمة عناصر لها id وموضوع وحالة و attempt و nextRetryAt و externalId ونتيجة. عند سحب العنصر، استخدم انتقالًا ذريًا يضمن ألا يسحبه عاملان معًا. إذا كانت قاعدة البيانات مشتركة، فالانتقالات المشروطة أو القفل المناسب أكثر أمانًا من نسخ ملف JSON وتعديله من عمليتين دون توافق. وإذا استعملت ملفًا صغيرًا، فاكتب إلى ملف مؤقت ثم استبدله ذريًا ولا تخاطر بقطع الكتابة في المنتصف.

ضع idempotency key عند التعامل مع عمليات إنشاء المقالات أو إرسال الملفات. قبل الإنشاء ابحث عن وجود العمل بالمعرف أو slug المحجوز، ثم أعد استخدام نتيجته إذا كانت موجودة. لا يكفي منع تكرار العنوان النصي لأن العناوين قد تختلف قليلًا رغم أن المحتوى نفسه متكرر. احتفظ بتوقيع نية المقال وسجل كلمات مفتاحية وبصمة للموضوع لكي تراجع التعارض بين الدورات كل 48 ساعة.

إعادة المحاولة دون عاصفة ضغط

ليست كل الأخطاء متساوية. فشل اتصال مؤقت قد يستحق ثلاث محاولات مع backoff وتأخير عشوائي، أما بيانات الاعتماد الخاطئة أو رفض صلاحيات مستمر فيجب إيقافه وإظهاره للمشرف بدل تكراره بلا نهاية. الأخطاء التي تقع بعد عملية خارجية ناجحة وقبل حفظ النتيجة تتطلب فحص حالة العملية الخارجية أولًا، وإلا قد تكرر آثارها. استخدم حدًا أعلى لعدد المحاولات وسجل سبب التأجيل وتاريخ انتهاء فترة الانتظار.

تجنب أن تطلق مهمة جديدة فور انتهاء القديمة إذا كان الجهاز تحت ضغط شديد. تحقق من available memory ومن جاهزية الموقع وعدد العمال قبل بدء العمل. لا تحول فشل اتصال قاعدة البيانات إلى سيل من خمسين عاملاً يحاولون الاتصال كل ثانية. استخدام صف انتظار محدود ورفض مبكر لبعض الأعمال أفضل من السماح بنمو لا نهائي يجعل الخدمة العامة تتوقف.

ما الذي يحدث عند إعادة تشغيل السيرفر؟

إذا كان Persistent=true فقد يحاول المؤقت التعويض عن وقت تعطل الخادم؛ وهذه خاصية ينبغي فهمها لا تعطيلها عشوائيًا. تأكد أن طابورك يستطيع التمييز بين مهمة لم تبدأ وأخرى بدأت ثم انقطعت، مع تاريخ lease أو heartbeat وحالة قابلة للتعافي. إعادة العمل بعد crash ينبغي أن تكون متوقعة وقابلة للتدقيق، لا تخمينًا بناءً على عدد الأسطر الموجودة في سجل التشغيل.

اختبر سيناريو قطع الطاقة أو إنهاء العملية أثناء الكتابة. هل يبقى معرف المقال الناتج محفوظًا؟ هل يمكن استعادة طابور الصور دون فقد المهمة؟ هل يكرر العامل مقالًا سبق جدولته؟ إذا كانت الإجابة غير معروفة، فلا تبدأ بإضافة مزيد من التزامن؛ أضف أولًا طبقة هوية ونتائج ومراجعة تعارض. يختلف ذلك عن إيقاف جميع المهام الثقيلة نهائيًا؛ المطلوب سلامة الاستمرار.

من النموذج إلى التشغيل الآمن

نفذ اختبارًا مصغرًا بثلاث مهام: واحدة تنتهي بسرعة، وأخرى تتأخر عن فترة المؤقت، وثالثة تفشل بعد إنشاء أثر خارجي. راقب ألا يتجاوز التزامن القيمة المحددة وألا يُنشأ الأثر مرتين وألا يختفي من الطابور عنصر غير مكتمل. ثم راجع حالة Timer وسجل systemd ووحدة transient وملف النتيجة. إذا نجح النموذج في الفشل المصطنع ستكون لديك ثقة أعلى عند التعامل مع أحداث حقيقية.

راجع مرجع systemd.timer ووثيقة systemd.service في freedesktop.org، وصفحات flock من util-linux للخيارات الدقيقة. تجنب نقل ملف وحدة جاهز من سياق مختلف دون اختبار Type و TimeoutStartSec و RuntimeMaxSec. المعيار الأخير هو عمل واحد منطقي لكل id، وسجل نتيجة موثوق، وعدد عمال محدود، وعدم التأثير على أداء الموقع حتى عندما يفشل مصدر صور أو شبكة خارجية.

قائمة تحقق تشغيلية مختصرة

قبل تمكين الجدولة: تحقق من اسم الوحدة والخدمة، واختبر الأمر دون timer، وتأكد من القفل ومن إدارة الأبناء، ثم اختبر انتهاء المهلة وسيناريو الفشل والرجوع. بعد التمكين راقب عدد تشغيلات الساعة وعدد العناصر المكتملة والمؤجلة ومتوسط زمن المهمة والذاكرة المتاحة. احرص على أن لا تستخدم دورة واحدة 15 دقيقة لإنشاء خمس مقالات إذا كان التنفيذ يستغرق أكثر من ذلك دون تخطيط لحجز المواعيد مسبقًا.

يمكن تطبيق المنهج نفسه على التحليلات ورسائل البريد والمزامنة وصناعة الصور ونقل الملفات. لا توجد فائدة من تسريع الإطلاق إذا فقدنا القدرة على استئناف العمل بوضوح. الوتيرة الموثوقة هي التي تنتج عنصرًا مكتملًا قابلًا للتحقق، وتسمح بفترات انتظار خالية من عمليات معلقة، وتمنع الخطأ السابق من تكرار التأثير على الزائر.