يُعرِّف مؤقتات رتيبة بالنسبة لنقاط بدء مختلفة:

جدول 1. الإعدادات ونقاط بدئها

الإعداد	المعنى
OnActiveSec=	يُعرِّف مؤقتًا بالنسبة للحظة التي تُفعّل فيها وحدة المؤقت نفسها.
OnBootSec=	يُعرِّف مؤقتًا بالنسبة لوقت إقلاع الجهاز. في الحاويات، بالنسبة لمثيل مدير النظام، يُرسم هذا إلى OnStartupSec=، مما يجعلهما متكافئين.
OnStartupSec=	يُعرِّف مؤقتًا بالنسبة لوقت بدء تشغيل مدير الخدمة لأول مرة. بالنسبة لوحدات مؤقت النظام، هذا مشابه جدًا لـ OnBootSec= حيث يُبدأ مدير خدمة النظام عمومًا في وقت مبكر جدًا عند الإقلاع. إنه مفيد بشكل أساسي عند تهيئته في وحدات تعمل في مدير الخدمة لكل مستخدم، حيث يُبدأ مدير خدمة المستخدم عمومًا عند أول تسجيل دخول فقط، وليس بالفعل أثناء الإقلاع.
OnUnitActiveSec=	يُعرِّف مؤقتًا بالنسبة لآخر مرة فُعّلت فيها الوحدة التي تفعّلها وحدة المؤقت.
OnUnitInactiveSec=	يُعرِّف مؤقتًا بالنسبة لآخر مرة أُلغي فيها تنشيط الوحدة التي تفعّلها وحدة المؤقت.

يمكن دمج توجيهات متعددة من نفس النوع ومن أنواع مختلفة، وفي هذه الحالة ستُفعّل وحدة المؤقت كلما انقضى أي من تعبيرات المؤقت المحددة. على سبيل المثال، بدمج OnBootSec= و OnUnitActiveSec=، يمكن تعريف مؤقت ينقضي على فترات منتظمة ويُفعّل خدمة محددة في كل مرة. علاوة على ذلك، يمكن دمج تعبيرات الوقت الرتيبة وتعبيرات التقويم OnCalendar= في نفس وحدة المؤقت.

الوسائط للتوجيهات هي فترات زمنية مُهيأة بالثواني. مثال: "OnBootSec=50" تعني 50 ثانية بعد الإقلاع. قد تتضمن الوسيطة أيضًا وحدات زمنية. مثال: "OnBootSec=5h 30min" تعني 5 ساعات و30 دقيقة بعد الإقلاع. للتفاصيل حول صياغة الفترات الزمنية، انظر systemd.time(7).

إذا كان مؤقت مُهيأ بـ OnBootSec= أو OnStartupSec= قد مضى بالفعل عند تفعيل وحدة المؤقت، فسينقضي فورًا وستُبدأ الوحدة المُهيأة. هذا ليس هو الحال للمؤقتات المُعرفة في التوجيهات الأخرى.

هذه مؤقتات رتيبة، مستقلة عن وقت الساعة الحائطية والمناطق الزمنية. إذا عُلّق الكمبيوتر مؤقتًا، تتوقف الساعة الرتيبة عمومًا أيضًا. لاحظ أنه إذا استُخدم WakeSystem=، فتُختار ساعة رتيبة مختلفة تستمر في التقدم أثناء تعليق النظام وبالتالي يمكن استخدامها كمُحفّز لاستئناف النظام.

إذا عُيّنت السلسلة الفارغة لأي من هذه الخيارات، فتُعاد تعيين قائمة المؤقتات (كل من المؤقتات الرتيبة ومؤقتات OnCalendar=، انظر أدناه)، ولن يكون لجميع التعيينات السابقة أي تأثير.

لاحظ أن المؤقتات لا تنقضي بالضرورة في الوقت المحدد المُهيأ بهذه الإعدادات، لأنها تخضع لإعداد AccuracySec= أدناه.

يُعرف مؤقتات زمنية حقيقية (أي ساعة حائطية) بتعبيرات أحداث تقويمية. انظر systemd.time(7) لمزيد من المعلومات حول صياغة تعبيرات الأحداث التقويمية. بخلاف ذلك، فإن الدلالات مشابهة لـ OnActiveSec= والإعدادات ذات الصلة.

لاحظ أن المؤقتات لا تنقضي بالضرورة في الوقت المحدد المُهيأ بهذا الإعداد، لأنه يخضع لإعداد AccuracySec= أدناه.

يمكن تحديده أكثر من مرة، وفي هذه الحالة ستُفعّل وحدة المؤقت كلما انقضى أي من التعبيرات المحددة. علاوة على ذلك، يمكن دمج المؤقتات التقويمية والمؤقتات الرتيبة (انظر أعلاه) داخل نفس وحدة المؤقت.

إذا عُيّنت السلسلة الفارغة لأي من هذه الخيارات، فتُعاد تعيين قائمة المؤقتات (كل من مؤقتات OnCalendar= والمؤقتات الرتيبة، انظر أعلاه)، ولن يكون لجميع التعيينات السابقة أي تأثير.

لاحظ أن المؤقتات التقويمية قد تُفعّل في أوقات غير متوقعة إذا لم تكن ساعة الوقت الحقيقي للنظام مضبوطة بشكل صحيح. تحديدًا، على الأنظمة التي تفتقر إلى ساعة وقت حقيقي (RTC) مدعومة ببطارية، قد يكون من الحكمة تمكين systemd-time-wait-sync.service لضمان ضبط الساعة على مصدر وقت شبكي قبل إعداد حدث المؤقت. وحدات المؤقت التي تحتوي على تعبير OnCalendar= واحد على الأقل تُرتّب آليًا بعد time-sync.target، والذي يُرتّب systemd-time-wait-sync.service قبله.

عندما يُوضع النظام في حالة سكون مؤقت (أي تعليق النظام أو الإسبات)، لا تتوقف ساعة الوقت الحقيقي. عندما ينقضي مؤقت تقويمي أثناء نوم النظام، لن يُتعامل معه فورًا، ولكن بمجرد استئناف النظام لاحقًا، سيلحق بالركب ويعالج جميع المؤقتات التي تفعّلت أثناء نوم النظام. لاحظ أنه إذا انقضى مؤقت تقويمي أكثر من مرة أثناء نوم النظام المستمر، فسيؤدي المؤقت إلى تفعيل خدمة واحدة فقط. إذا كان WakeSystem= (انظر أدناه) مُفعّلاً، فإن حدث وقت تقويمي ينقضي أثناء تعليق النظام سيؤدي إلى إيقاظ النظام (بشرط أن تدعم أجهزة النظام وظيفة الإيقاظ المُحفّز بالوقت).

أُضيف في الإصدارة 197.

حدد الدقة التي سينقضي بها المؤقت. المبدئي هو 1 دقيقة. يُجدول المؤقت للانقضاء ضمن نافذة زمنية تبدأ بالوقت المحدد في OnCalendar=، OnActiveSec=، OnBootSec=، OnStartupSec=، OnUnitActiveSec= أو OnUnitInactiveSec= وتنتهي بالوقت المُهيأ بـ AccuracySec= لاحقًا. ضمن هذه النافذة الزمنية، سيُوضع وقت الانتهاء في موضع خاص بالمضيف، عشوائي، لكن مستقر ومتزامن بين جميع وحدات المؤقت المحلية. يُفعل ذلك لتحسين استهلاك الطاقة لقمع إيقاظات وحدة المعالجة المركزية غير الضرورية. للحصول على أفضل دقة، اضبط هذا الخيار على 1 ميكروثانية. لاحظ أن المؤقت لا يزال خاضعًا لتراخي المؤقت المُهيأ عبر إعداد TimerSlackNSec= في systemd-system.conf(5). انظر prctl(2) للتفاصيل. لتحسين استهلاك الطاقة، تأكد من ضبط هذه القيمة بأعلى ما يمكن وأقل ما يلزم.

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

أُضيف في الإصدارة 209.

أخّر المؤقت بمقدار زمني مُختار عشوائيًا وموزع بالتساوي بين 0 وقيمة الوقت المحددة. المبدئي هو 0، مما يشير إلى عدم تطبيق أي تأخير عشوائي. ستحدد كل وحدة مؤقت هذا التأخير عشوائيًا قبل كل تكرار، ما لم يُعدّل بـ FixedRandomDelay=، انظر أدناه. يُضاف التأخير فوق وقت الانقضاء المُحدد التالي أو وقت بدء مدير الخدمة، أيهما أحدث.

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

لاحظ العلاقة مع AccuracySec= أعلاه: الأخير يسمح لمدير الخدمة بتجميع أحداث المؤقت ضمن نطاق زمني محدد لتقليل الإيقاظات، بينما يفعل هذا الإعداد العكس: فهو يمدد أحداث المؤقت على فترة، مما يجعل من غير المحتمل أن تُطلق في وقت واحد. إذا استُخدم RandomizedDelaySec= و AccuracySec= معًا، يُضاف التأخير العشوائي أولاً، ثم يُزاح النتيجة ربما بشكل أكبر لتجميعها مع أحداث مؤقت أخرى تحدث على النظام. كما ذُكر أعلاه، المبدئي لـ AccuracySec= هو دقيقة واحدة ولـ RandomizedDelaySec= هو 0، مما يشجع على تجميع أحداث المؤقت. لتمديد أحداث المؤقت بشكل مثالي على نطاق معين من الوقت، اضبط AccuracySec=1us و RandomizedDelaySec= على قيمة أعلى.

أُضيف في الإصدارة 229.

يأخذ وسيطة منطقية. عند التمكين، يُختار التأخير العشوائي المحدد بـ RandomizedDelaySec= بشكل حتمي، ويظل مستقرًا بين جميع إطلاقات نفس المؤقت، حتى إذا أُعيد تشغيل المدير. يُشتق التأخير من معرف الجهاز، ومعرف مستخدم المدير، واسم وحدة المؤقت. هذا يُنشئ بشكل فعال إزاحة ثابتة فريدة لكل مؤقت، مما يقلل من التذبذب في إطلاقات مؤقت فردي مع تجنب الإطلاق في نفس الوقت مع مؤقتات أخرى مُهيأة بشكل مشابه.

هذا الإعداد له تأثير فقط إذا كان RandomizedDelaySec= ليس 0. الافتراضيين إلى false.

أُضيف في الإصدار 247.

تُزيح الموقت بمقدار زمني ثابت، ومختار عشوائيًا، وموزع بانتظام بين 0 وقيمة الوقت المحددة. القيمة المبدئية هي 0، مما يشير إلى أنه لن يُطبق أي إزاحة من هذا النوع. تُختار الإزاحة بطريقة حتمية، وتُشتق بنفس الطريقة المتبعة في FixedRandomDelay=، انظر أعلاه. تُضاف الإزاحة فوق وقت الانقضاء المحدد التالي. لا يكون لهذا الإعداد تأثير إلا على الموقتات المهيأة باستخدام OnCalendar=، ويمكن دمجه مع RandomizedDelaySec=.

يشبه هذا الإعداد إلى حد كبير RandomizedDelaySec=، حيث يُستخدم لتوزيع أحداث المؤقت لمنع إطلاقها جميعًا مرة واحدة. ومع ذلك، فإن هذا الإعداد مفيد جدًا لمنع ازدحام الموارد على خدمة بعيدة، من مجموعة من العملاء المكونة بشكل مماثل. على عكس RandomizedDelaySec=، يطبق هذا الإعداد إزاحته دون اعتبار لوقت بدء تشغيل المدير. يحافظ هذا على دورية أحداث OnCalendar= المكونة عبر عمليات إعادة تشغيل المدير.

على سبيل المثال، لنفترض أنك تدير خدمة نسخ احتياطي ولديك مجموعة من أجهزة الكمبيوتر المحمولة التي ترغب في عمل نسخ احتياطية أسبوعيًا. لتوزيع الحمل على خدمة النسخ الاحتياطي، يجب أن يختار كل كمبيوتر محمول يومًا عشوائيًا من أيام الأسبوع لتحميل نسخه الاحتياطية. يمكن تحقيق ذلك عن طريق تعيين OnCalendar= إلى "weekly"، ثم تكوين RandomizedDelaySec= بقيمة "5 days" مع تمكين FixedRandomDelay=. لنفترض أن بعض أجهزة الكمبيوتر المحمولة تختار عشوائيًا تأخيرًا لمدة 4 أيام. إذا تمت إعادة تشغيل هذا الكمبيوتر المحمول أكثر من ذلك، فلن يتم إطلاق المؤقت أبدًا: في كل إقلاع جديد، يتم إعادة تشغيل التأخير لمدة 4 أيام ولن ينتهي بحلول وقت الإغلاق التالي. بدلاً من ذلك، يجب استخدام RandomizedOffsetSec=، الذي سيحافظ على الإيقاع الأسبوعي المكون لأحداث المؤقت، حتى عبر عمليات إعادة التشغيل.

أُضيف في الإصدار 258.

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

يكون لهذا الإعداد تأثير فقط إذا تم تحديد مؤقت زمني حقيقي باستخدام OnCalendar=. المبدئي هو false.

أُضيف في الإصدار 257.

تقبل هذه الخيارات وسائط منطقية. عندما تكون صحيحة، سيتم تشغيل وحدة الخدمة عندما تقفز ساعة النظام (CLOCK_REALTIME) بالنسبة للساعة الرتيبة (CLOCK_MONOTONIC)، أو عند تعديل المنطقة الزمنية للنظام المحلي. يمكن استخدام هذه الخيارات بمفردها أو بالاشتراك مع تعبيرات مؤقت أخرى (انظر أعلاه) داخل نفس وحدة المؤقت. المبدئي لهذه الخيارات هو false.

أُضيف في الإصدارة 242.

الوحدة التي سيتم تنشيطها عند انقضاء هذا المؤقت. الوسيط هو اسم وحدة، لا يكون لاحقته ".timer". إذا لم يتم تحديده، تكون القيمة المبدئية لخدمة لها نفس اسم وحدة المؤقت، باستثناء اللاحقة. (انظر أعلاه.) يُوصى بأن يكون اسم الوحدة التي يتم تنشيطها واسم وحدة المؤقت متطابقين، باستثناء اللاحقة.

يقبل وسيطًا منطقيًا. إذا كان صحيحًا، يتم تخزين وقت آخر تشغيل لوحدة الخدمة على القرص. عند تنشيط المؤقت، يتم تشغيل وحدة الخدمة فورًا إذا كان من الممكن أن تكون قد تم تشغيلها مرة واحدة على الأقل خلال الوقت الذي كان فيه المؤقت غير نشط. ومع ذلك، يخضع هذا التشغيل للتأخير الذي يفرضه RandomizedDelaySec=. هذا مفيد للحاق بتشغيلات الخدمة الفائتة عند إيقاف تشغيل النظام. لاحظ أن هذا الإعداد يؤثر فقط على المؤقتات المكونة باستخدام OnCalendar=. المبدئي هو false.

استخدم systemctl clean --what=state ... على وحدة المؤقت لإزالة ملف الطابع الزمني الذي يحتفظ به هذا الخيار من القرص. على وجه الخصوص، استخدم هذا الأمر قبل إلغاء تثبيت وحدة مؤقت. راجع systemctl(1) للحصول على التفاصيل.

أُضيف في الإصدارة 212.

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

لاحظ أن هذه الوظيفة تتطلب امتيازات وبالتالي فهي متاحة بشكل عام فقط في مدير خدمة النظام.

لاحظ أن سلوك مؤقتات الساعة الرتيبة (كما تم تكوينها باستخدام OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=، انظر أعلاه) يتغير اعتمادًا على هذا الخيار. إذا كان خطأ، يتم استخدام ساعة رتيبة يتم إيقافها مؤقتًا أثناء سكون النظام (CLOCK_MONOTONIC)، وإذا كان صحيحًا، يتم استخدام ساعة رتيبة مختلفة تستمر في التقدم أثناء سكون النظام (CLOCK_BOOTTIME)، راجع clock_getres(2) للحصول على التفاصيل.

أُضيف في الإصدارة 212.

يقبل وسيطًا منطقيًا. إذا كان صحيحًا، سيبقى المؤقت محملاً، وستظل حالته قابلة للاستعلام حتى بعد انقضائه وإلغاء تنشيط الوحدة المرتبطة (كما تم تكوينها باستخدام Unit=، انظر أعلاه) مرة أخرى. إذا كان خطأ، يتم إلغاء تحميل وحدة مؤقت منقضية لا يمكن أن تنقضي مرة أخرى بمجرد إلغاء تنشيط الوحدة المرتبطة بها مرة أخرى. يكون إيقاف تشغيل هذا مفيدًا بشكل خاص لوحدات المؤقت المؤقتة. لاحظ أن هذا الإعداد له تأثير عند بدء تشغيل وحدة مؤقت بشكل متكرر: إذا كان RemainAfterElapse= قيد التشغيل، فإن بدء تشغيل المؤقت مرة ثانية ليس له تأثير. ومع ذلك، إذا كان RemainAfterElapse= متوقفًا عن التشغيل وتم إلغاء تحميل وحدة المؤقت بالفعل، فيمكن بدء تشغيلها مرة أخرى، وبالتالي يمكن تشغيل الخدمة عدة مرات. المبدئي هو true.

أُضيف في الإصدارة 229.