SYSTEMD.TIMER(5) systemd.timer SYSTEMD.TIMER(5)

systemd.timer - پیکربندی واحد تایمر

timer.timer

یک فایل پیکربندی واحد که نام آن به ".timer" ختم می‌شود، اطلاعات مربوط به یک تایمر تحت کنترل و نظارت systemd را برای فعال‌سازی مبتنی بر زمان کدگذاری می‌کند.

این صفحه راهنما، گزینه‌های پیکربندی مخصوص این نوع واحد را فهرست می‌کند. برای گزینه‌های مشترک تمام فایل‌های پیکربندی واحد، systemd.unit(5) را ببینید. موارد پیکربندی مشترک در بخش‌های عمومی [Unit] و [Install] پیکربندی می‌شوند. گزینه‌های پیکربندی مخصوص تایمر در بخش [Timer] پیکربندی می‌شوند.

برای هر فایل تایمر، باید یک فایل واحد منطبق وجود داشته باشد که واحدی را که باید با سپری شدن زمان تایمر فعال شود توصیف کند. به‌طور پیش‌فرض، سرویسی با همان نام تایمر (به جز پسوند) فعال می‌شود. برای مثال: یک فایل تایمر foo.timer سرویس منطبق foo.service را فعال می‌کند. واحدی که باید فعال شود ممکن است توسط Unit= (به زیر مراجعه کنید) کنترل شود.

توجه داشته باشید که در صورتی که واحد مورد نظر برای فعال‌سازی در زمان سپری شدن تایمر از قبل فعال باشد، مجدداً راه‌اندازی نمی‌شود، بلکه صرفاً در حال اجرا باقی می‌ماند. در این حالت هیچ مفهومی از ایجاد نمونه‌های جدید سرویس وجود ندارد. به همین دلیل، سرویس‌هایی که گزینه RemainAfterExit=yes برای آن‌ها تنظیم شده است (که حتی پس از خروج فرآیند اصلی سرویس همچنان فعال باقی می‌مانند) معمولاً برای فعال‌سازی از طریق تایمرهای تکرارشونده مناسب نیستند، زیرا تنها یک‌بار فعال می‌شوند و پس از آن برای همیشه فعال می‌مانند. واحدهای هدف (Target units) که به‌طور پیش‌فرض به خودی خود غیرفعال نمی‌شوند، می‌توانند با تنظیم StopWhenUnneeded=yes بر روی آن‌ها، به‌طور مکرر توسط تایمرها فعال شوند. این کار باعث می‌شود در صورتی که واحد هدف وابستگی واحد در حال اجرای دیگری نباشد، بلافاصله پس از فعال‌سازی متوقف شود.

وابستگی‌های زیر به‌طور ضمنی اضافه می‌شوند:

•واحدهای تایمر به‌طور خودکار یک وابستگی Before= نسبت به سرویسی که قرار است فعال کنند به دست می‌آورند.

وابستگی‌های زیر اضافه می‌شوند مگر اینکه DefaultDependencies=no تنظیم شده باشد:

•واحدهای تایمر به‌طور خودکار وابستگی‌هایی از نوع Requires= و After= به sysinit.target، یک وابستگی از نوع Before= به timers.target، و همچنین Conflicts= و Before= به shutdown.target خواهند داشت تا اطمینان حاصل شود که پیش از خاموش شدن سیستم به‌طور پاک متوقف می‌شوند. تنها واحدهای تایمری که در مراحل اولیه بوت یا مراحل پایانی خاموش شدن سیستم دخیل هستند باید گزینه DefaultDependencies= را غیرفعال کنند.
•واحدهای تایمر با حداقل یک دستورالعمل OnCalendar=، یک جفت وابستگی اضافی After= به time-set.target و time-sync.target به دست می‌آورند تا از شروع آن‌ها پیش از تنظیم صحیح ساعت سیستم جلوگیری شود. برای جزئیات مربوط به این دو هدف، systemd.special(7) را ببینید.

فایل‌های واحد تایمر ممکن است شامل بخش‌های [Unit] و [Install] باشند که در systemd.unit(5) شرح داده شده‌اند.

فایل‌های واحد تایمر باید شامل یک بخش [Timer] باشند که حامل اطلاعات مربوط به تایمر تعریف‌شده است. گزینه‌های مخصوص بخش [Timer] واحدهای تایمر به شرح زیر است:

OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=

تایمرهای یکنواخت (monotonic timers) را نسبت به نقاط شروع مختلف تعریف می‌کند:

جدول ۱. تنظیمات و نقاط شروع آن‌ها

تنظیم مفهوم
OnActiveSec= تایمری را نسبت به لحظه فعال شدن خودِ واحد تایمر تعریف می‌کند.
OnBootSec= تایمری را نسبت به زمان بوت شدن ماشین تعریف می‌کند. در کانتینرها، برای نمونه مدیر سیستم، این گزینه به OnStartupSec= نگاشت می‌شود که هر دو را معادل می‌سازد.
OnStartupSec= تایمری را نسبت به زمانی که مدیر سرویس برای نخستین بار شروع شد تعریف می‌کند. برای واحدهای تایمر سیستمی، این گزینه بسیار شبیه به OnBootSec= است زیرا مدیر سرویس سیستم معمولاً خیلی زود در هنگام بوت شروع می‌شود. این گزینه عمدتاً زمانی کاربرد دارد که در واحدهایی پیکربندی شود که در مدیر سرویس به ازای کاربر اجرا می‌شوند، زیرا مدیر سرویس کاربر عموماً تنها در نخستین ورود به سیستم شروع می‌شود، نه در هنگام بوت.
OnUnitActiveSec= تایمری را نسبت به آخرین باری که واحد فعال‌شونده توسط واحد تایمر فعال شده بود تعریف می‌کند.
OnUnitInactiveSec= تایمری را نسبت به آخرین باری که واحد فعال‌شونده توسط واحد تایمر غیرفعال شده بود تعریف می‌کند.

می‌توان چندین دستورالعمل از یک نوع یا از انواع مختلف را ترکیب کرد، که در این صورت هر زمان که هر یک از عبارت‌های تایمر مشخص‌شده سپری شود، واحد تایمر فعال خواهد شد. برای مثال، با ترکیب
OnBootSec= و OnUnitActiveSec=، امکان تعریف تایمری وجود دارد که در فواصل زمانی منظم منقضی شده و هر بار یک سرویس خاص را فعال کند. علاوه بر این، هم عبارت‌های زمانی یکنواخت و هم عبارت‌های تقویمی OnCalendar= می‌توانند در یک واحد تایمر یکسان ترکیب شوند.

آرگومان‌های این دستورالعمل‌ها بازه‌های زمانی هستند که بر حسب ثانیه پیکربندی می‌شوند. مثال: "OnBootSec=50" به معنی ۵۰ ثانیه پس از بوت است. آرگومان همچنین می‌تواند شامل واحدهای زمانی باشد. مثال: "OnBootSec=5h 30min" به معنی ۵ ساعت و ۳۰ دقیقه پس از بوت است. برای جزئیات درباره نحو بازه‌های زمانی، systemd.time(7) را ببینید.

اگر تایمری که با OnBootSec= یا OnStartupSec= پیکربندی شده است، در زمان فعال شدن واحد تایمر در گذشته قرار داشته باشد، بلافاصله منقضی شده و واحد پیکربندی‌شده شروع می‌شود. این موضوع در مورد تایمرهای تعریف‌شده در سایر دستورالعمل‌ها صدق نمی‌کند.

این‌ها تایمرهای یکنواخت، و مستقل از ساعت دیواری و مناطق زمانی هستند. اگر رایانه موقتاً به حالت تعلیق درآید، ساعت یکنواخت نیز عموماً متوقف می‌شود. توجه داشته باشید که اگر از WakeSystem= استفاده شود، ساعت یکنواخت متفاوتی انتخاب می‌شود که در زمان تعلیق سیستم نیز به پیشروی ادامه می‌دهد و بنابراین می‌تواند به عنوان محرکی برای ازسرگیری کار سیستم استفاده شود.

اگر رشته خالی به هر یک از این گزینه‌ها اختصاص داده شود، فهرست تایمرها بازنشانی می‌شود (هم تایمرهای یکنواخت و هم تایمرهای OnCalendar=، به زیر مراجعه کنید)، و تمام انتساب‌های قبلی بی‌اثر خواهند شد.

توجه داشته باشید که تایمرها لزوماً دقیقاً در زمان پیکربندی‌شده با این تنظیمات منقضی نمی‌شوند، زیرا مشمول تنظیم AccuracySec= در زیر هستند.

OnCalendar=

تایمرهای بلادرنگ (یعنی ساعت دیواری) را با عبارت‌های رویداد تقویمی تعریف می‌کند. برای اطلاعات بیشتر درباره نحو عبارت‌های رویداد تقویمی، systemd.time(7) را ببینید. در غیر این صورت، معناشناسی آن شبیه به OnActiveSec= و تنظیمات مرتبط با آن است.

توجه داشته باشید که تایمرها لزوماً دقیقاً در زمان پیکربندی‌شده با این تنظیم منقضی نمی‌شوند، زیرا مشمول تنظیم AccuracySec= در زیر هستند.

می‌تواند بیش از یک‌بار مشخص شود، که در این صورت هر زمان که هر یک از عبارت‌های مشخص‌شده سپری شود، واحد تایمر فعال خواهد شد. علاوه بر این، تایمرهای تقویمی و تایمرهای یکنواخت (به بالا مراجعه کنید) می‌توانند در یک واحد تایمر یکسان ترکیب شوند.

اگر رشته خالی به هر یک از این گزینه‌ها اختصاص داده شود، فهرست تایمرها بازنشانی می‌شود (هم تایمرهای OnCalendar= و هم تایمرهای یکنواخت، به بالا مراجعه کنید)، و تمام انتساب‌های قبلی بی‌اثر خواهند شد.

توجه داشته باشید اگر ساعت بلادرنگ سیستم به‌درستی تنظیم نشده باشد، تایمرهای تقویمی ممکن است در زمان‌های غیرمنتظره‌ای فعال شوند. به‌ویژه در سیستم‌هایی که فاقد ساعت بلادرنگ باتری‌دار (RTC) هستند، عاقلانه است که systemd-time-wait-sync.service فعال شود تا اطمینان حاصل گردد که ساعت سیستم پیش از تنظیم رویداد تایمر با یک منبع زمان شبکه همگام‌سازی می‌شود. واحدهای تایمر با حداقل یک عبارت OnCalendar= به‌طور خودکار پس از time-sync.target مرتب می‌شوند، که systemd-time-wait-sync.service پیش از آن مرتب می‌شود.

هنگامی که سیستم موقتاً به حالت خواب می‌رود (یعنی تعلیق یا خواب‌زمستانی سیستم)، ساعت بلادرنگ متوقف نمی‌شود. اگر یک تایمر تقویمی در حین خواب بودن سیستم منقضی شود، بلافاصله روی آن اقدامی صورت نمی‌گیرد، اما پس از اینکه سیستم بعداً ازسرگرفته شد، عقب‌ماندگی را جبران کرده و تمام تایمرهایی را که در زمان خواب بودن سیستم فعال شده بودند پردازش می‌کند. توجه داشته باشید که اگر یک تایمر تقویمی در حین خواب پیوسته سیستم بیش از یک‌بار منقضی شده باشد، این تایمر تنها منجر به یک‌بار فعال‌سازی سرویس خواهد شد. اگر WakeSystem= (به زیر مراجعه کنید) فعال باشد، منقضی شدن یک رویداد زمان تقویمی در زمان تعلیق سیستم باعث بیدار شدن سیستم خواهد شد (به شرطی که سخت‌افزار سیستم از قابلیت بیدار شدن با محرک زمان پشتیبانی کند).

در نسخه 197 اضافه شد.

AccuracySec=

دقتی را که تایمر باید با آن منقضی شود مشخص می‌کند. مقدار پیش‌فرض 1min است. تایمر طوری زمان‌بندی می‌شود که درون یک پنجره زمانی منقضی شود که با زمان مشخص‌شده در OnCalendar=، OnActiveSec=، OnBootSec=، OnStartupSec=، OnUnitActiveSec= یا OnUnitInactiveSec= شروع می‌شود و در زمانی به اندازه AccuracySec= بعدتر به پایان می‌رسد. درون این پنجره زمانی، زمان انقضا در یک موقعیت تصادفی اما پایدار و مختص به میزبان قرار می‌گیرد که میان تمام واحدهای تایمر محلی همگام‌سازی شده است. این کار به منظور بهینه‌سازی مصرف انرژی و جلوگیری از بیدار شدن‌های غیرضروری پردازنده انجام می‌شود. برای دستیابی به بالاترین دقت، این گزینه را روی 1us تنظیم کنید. توجه داشته باشید که تایمر همچنان مشمول فرجه تایمر پیکربندی‌شده از طریق تنظیم TimerSlackNSec= در systemd-system.conf(5) است. برای جزئیات، prctl(2) را ببینید. برای بهینه‌سازی مصرف انرژی، اطمینان حاصل کنید که این مقدار را تا جای ممکن بالا و تا جای لازم پایین تنظیم کنید.

توجه داشته باشید که این تنظیم عمدتاً یک گزینه صرفه‌جویی در مصرف انرژی است که امکان ادغام بیدار شدن‌های پردازنده را فراهم می‌آورد. این گزینه نباید با RandomizedDelaySec= (به زیر مراجعه کنید) اشتباه گرفته شود که یک مقدار تصادفی را به زمان بعدی انقضای تایمر اضافه می‌کند و هدف آن عکس این است: توزیع انقضای رویدادهای تایمر در یک دوره طولانی‌تر به منظور کاهش جهش‌های بار کاری. برای جزئیات و توضیحات بیشتر و نحوه عملکرد هم‌زمان هر دو تنظیم، به زیر مراجعه کنید.

در نسخه 209 اضافه شد.

RandomizedDelaySec=

تایمر را به اندازه یک مقدار زمانی به‌طور تصادفی انتخاب‌شده و با توزیع یکنواخت بین 0 و مقدار زمانی مشخص‌شده به تأخیر می‌اندازد. مقدار پیش‌فرض 0 است که نشان می‌دهد هیچ تأخیر تصادفی‌ای اعمال نخواهد شد. هر واحد تایمر این تأخیر را پیش از هر تکرار به‌طور تصادفی تعیین می‌کند، مگر اینکه با FixedRandomDelay= تغییر داده شود، به زیر مراجعه کنید. این تأخیر بر روی زمان انقضای تعیین‌شده بعدی یا زمان راه‌اندازی مدیر سرویس (هرکدام که دیرتر باشد) افزوده می‌شود.

این تنظیم برای توزیع ارسال رویدادهای تایمر با پیکربندی مشابه در یک بازه زمانی معین مفید است، تا از فعال شدن هم‌زمان آن‌ها که احتمالاً منجر به ازدحام منابع در سیستم محلی می‌شود جلوگیری کند.

به رابطه با AccuracySec= در بالا توجه کنید: مورد دوم به مدیر سرویس اجازه می‌دهد تا رویدادهای تایمر را در یک محدوده زمانی مشخص ادغام کند تا بیدار شدن‌ها به حداقل برسد، در حالی که این تنظیم برعکس عمل می‌کند: رویدادهای تایمر را در یک بازه زمانی می‌گستراند تا احتمال اجرای هم‌زمان آن‌ها کاهش یابد. اگر RandomizedDelaySec= و AccuracySec= به‌طور مشترک استفاده شوند، ابتدا تأخیر تصادفی اضافه می‌شود و سپس نتیجه ممکن است بیشتر جابه‌جا شود تا با سایر رویدادهای تایمر رخ‌داده در سیستم ادغام شود. همان‌طور که در بالا ذکر شد، مقدار پیش‌فرض AccuracySec= برابر با ۱ دقیقه و مقدار پیش‌فرض RandomizedDelaySec= برابر با ۰ است که ادغام رویدادهای تایمر را ترغیب می‌کند. به منظور توزیع بهینه رویدادهای تایمر در یک بازه زمانی مشخص، AccuracySec=1us و RandomizedDelaySec= را روی مقداری بالاتر تنظیم کنید.

در نسخه 229 اضافه شد.

FixedRandomDelay=

یک آرگومان بولی می‌پذیرد. در صورت فعال بودن، تأخیر تصادفی مشخص‌شده توسط RandomizedDelaySec= به‌طور قطعی انتخاب می‌شود و بین تمام دفعات اجرای همان تایمر پایدار می‌ماند، حتی اگر مدیر سرویس راه‌اندازی مجدد شود. این تأخیر از شناسه ماشین، شناسه کاربری مدیر سرویس، و نام واحد تایمر مشتق می‌شود. این کار در عمل یک آفست ثابت و منحصر‌به‌فرد برای هر تایمر ایجاد می‌کند که نوسان در دفعات اجرای یک تایمر مجزا را کاهش می‌دهد در حالی که همچنان از اجرای هم‌زمان با سایر تایمرهای مشابه پیکربندی‌شده جلوگیری می‌کند.

این تنظیم تنها زمانی مؤثر است که RandomizedDelaySec= برابر با 0 نباشد. مقدار پیش‌فرض false است.

در نسخه 247 اضافه شد.

RandomizedOffsetSec=

تایمر را به اندازه یک مقدار زمانی پایدار، تصادفی انتخاب‌شده و با توزیع یکنواخت بین 0 و مقدار زمانی مشخص‌شده جابه‌جا می‌کند. مقدار پیش‌فرض 0 است که نشان می‌دهد چنین آفستی اعمال نخواهد شد. آفست به‌طور قطعی انتخاب می‌شود و به همان روش FixedRandomDelay= مشتق می‌گردد، به بالا مراجعه کنید. این آفست بر روی زمان انقضای تعیین‌شده بعدی افزوده می‌شود. این تنظیم تنها بر روی تایمرهایی که با OnCalendar= پیکربندی شده‌اند تأثیر دارد و می‌تواند با RandomizedDelaySec= ترکیب شود.

بسیار شبیه به RandomizedDelaySec=، این تنظیم نیز برای توزیع رویدادهای تایمر به منظور جلوگیری از اجرای هم‌زمان همه آن‌ها است. با این حال، این تنظیم بیش از همه برای جلوگیری از ازدحام منابع در یک سرویس راه دور توسط ناوگانی از کلاینت‌های با پیکربندی مشابه مفید است. برخلاف RandomizedDelaySec=، این تنظیم آفست خود را بدون توجه به زمان راه‌اندازی مدیر سرویس اعمال می‌کند. این امر تناوب رویدادهای OnCalendar= پیکربندی‌شده را در طول راه‌اندازی‌های مجدد مدیر سرویس حفظ می‌کند.

برای مثال، فرض کنید شما در حال اجرای یک سرویس پشتیبان‌گیری هستید و ناوگانی از لپ‌تاپ‌ها دارید که مایلند به‌طور هفتگی نسخه پشتیبان تهیه کنند. برای توزیع بار روی سرویس پشتیبان‌گیری، هر لپ‌تاپ باید به‌طور تصادفی یک روز کاری هفته را برای بارگذاری نسخه‌های پشتیبان خود انتخاب کند. این کار می‌تواند با تنظیم OnCalendar= روی "weekly" و سپس پیکربندی RandomizedDelaySec= به میزان "5 days" با فعال بودن FixedRandomDelay= انجام شود. فرض کنید یک لپ‌تاپ به‌طور تصادفی تأخیر ۴ روز را انتخاب کند. اگر این لپ‌تاپ زودتر از این مدت راه‌اندازی مجدد شود، تایمر هرگز اجرا نخواهد شد: در هر بوت جدید، تأخیر ۴ روزه مجدداً شروع می‌شود و تا زمان خاموش شدن بعدی به پایان نخواهد رسید. در عوض، باید از RandomizedOffsetSec= استفاده کنید که ریتم و تناوب هفتگی پیکربندی‌شده رویدادهای تایمر را حتی در طول راه‌اندازی‌های مجدد حفظ خواهد کرد.

در نسخه 258 اضافه شد.

DeferReactivation=

یک آرگومان بولی می‌پذیرد. در صورت فعال بودن، تایمر انقضای بعدی را بر اساس غیرفعال شدن واحد محرک، به جای زمان آخرین تحریک زمان‌بندی می‌کند. این موضوع بیشتر در حالتی مشهود است که اجرای واحد سرویس بیشتر از بازه زمانی تایمر طول بکشد. با فعال بودن این تنظیم، تایمر انقضای بعدی را بر اساس زمان پایان اجرای سرویس زمان‌بندی خواهد کرد و بنابراین برای تحریک شدن باید تا زمان انقضای بلادرنگ بعدی منتظر بماند. در غیر این صورت، رفتار پیش‌فرض این است که واحد تایمر بلافاصله پس از اتمام اجرای سرویس مجدداً فعال شود. این اتفاق به این دلیل رخ می‌دهد که تایمر انقضای بعدی را بر اساس زمان تحریک قبلی زمان‌بندی می‌کند، و از آنجا که بازه زمانی کوتاه‌تر از زمان اجرای سرویس است، آن زمان انقضا در گذشته قرار خواهد گرفت و باعث می‌شود به محض اتمام، فوراً دوباره فعال شود.

این تنظیم تنها در صورتی تأثیر دارد که یک تایمر بلادرنگ با OnCalendar= مشخص شده باشد. مقدار پیش‌فرض false است.

در نسخه 257 اضافه شد.

OnClockChange=, OnTimezoneChange=

این گزینه‌ها آرگومان‌های بولی می‌پذیرند. در صورت درست بودن، هنگامی که ساعت سیستم (CLOCK_REALTIME) نسبت به ساعت یکنواخت (CLOCK_MONOTONIC) جهش داشته باشد، یا زمانی که منطقه زمانی محلی سیستم تغییر کند، واحد سرویس فعال خواهد شد. این گزینه‌ها می‌توانند به تنهایی یا در ترکیب با سایر عبارت‌های تایمر (به بالا مراجعه کنید) در یک واحد تایمر یکسان استفاده شوند. مقدار پیش‌فرض این گزینه‌ها false است.

در نسخه 242 اضافه شد.

Unit=

واحدی که باید با سپری شدن این تایمر فعال شود. آرگومان یک نام واحد است که پسوند آن ".timer" نیست. اگر مشخص نشود، این مقدار به‌طور پیش‌فرض به سرویسی با همان نام واحد تایمر، به جز پسوند، تنظیم می‌شود. (به بالا مراجعه کنید.) توصیه می‌شود که نام واحد فعال‌شونده و نام واحد تایمر، به جز پسوند، یکسان نام‌گذاری شوند.

Persistent=

یک آرگومان بولی می‌پذیرد. در صورت درست بودن، زمانی که واحد سرویس آخرین بار فعال شده بود روی دیسک ذخیره می‌شود. هنگامی که تایمر فعال می‌شود، اگر سرویس در طول مدتی که تایمر غیرفعال بوده حداقل یک‌بار فعال می‌شده است، واحد سرویس بلافاصله فعال می‌گردد. چنین فعال‌سازی‌ای با این وجود مشمول تأخیر تحمیل‌شده توسط RandomizedDelaySec= خواهد بود. این قابلیت برای جبران اجراهای از دست رفته سرویس در زمان خاموش بودن سیستم مفید است. توجه داشته باشید که این تنظیم تنها بر روی تایمرهایی که با OnCalendar= پیکربندی شده‌اند تأثیر دارد. مقدار پیش‌فرض false است.

از دستور systemctl clean --what=state ... روی واحد تایمر استفاده کنید تا فایل برچسب زمانی نگهداری‌شده توسط این گزینه را از روی دیسک پاک کنید. به‌ویژه پیش از حذف نصب یک واحد تایمر از این دستور استفاده کنید. برای جزئیات، systemctl(1) را ببینید.

در نسخه 212 اضافه شد.

WakeSystem=

یک آرگومان بولی می‌پذیرد. در صورت درست بودن، با سپری شدن زمان تایمر، در صورتی که سیستم در حالت تعلیق باشد و سخت‌افزار سیستم از آن پشتیبانی کند، سیستم از حالت تعلیق خارج شده و ازسرگرفته می‌شود. توجه داشته باشید که این گزینه تنها اطمینان حاصل می‌کند که سیستم در زمان‌های مناسب بیدار شود، و پس از اتمام کارهایی که باید انجام شود، مسئولیتی در قبال تعلیق مجدد آن بر عهده نخواهد داشت. مقدار پیش‌فرض false است.

توجه داشته باشید که این عملکرد نیازمند دسترسی‌های ویژه است و بنابراین معمولاً تنها در مدیر سرویس سیستم در دسترس است.

توجه داشته باشید که رفتار تایمرهای ساعت یکنواخت (همان‌طور که با OnActiveSec=، OnBootSec=، OnStartupSec=، OnUnitActiveSec=، OnUnitInactiveSec= پیکربندی شده‌اند، به بالا مراجعه کنید) بسته به این گزینه تغییر می‌کند. اگر نادرست باشد، از یک ساعت یکنواخت استفاده می‌شود که در طول تعلیق سیستم متوقف می‌شود (CLOCK_MONOTONIC)؛ اگر درست باشد، از ساعت یکنواخت متفاوتی استفاده می‌شود که در طول تعلیق سیستم به پیشروی ادامه می‌دهد (CLOCK_BOOTTIME)؛ برای جزئیات، clock_getres(2) را ببینید.

در نسخه 212 اضافه شد.

RemainAfterElapse=

یک آرگومان بولی می‌پذیرد. در صورت درست بودن، تایمر بارگذاری‌شده باقی می‌ماند و وضعیت آن حتی پس از سپری شدن زمان و غیرفعال شدن مجدد واحد مرتبط (همان‌طور که با Unit= پیکربندی شده است، به بالا مراجعه کنید) قابل استعلام باقی می‌ماند. در صورت نادرست بودن، یک واحد تایمر سپری‌شده که دیگر نمی‌تواند منقضی شود، به محض غیرفعال شدن مجدد واحد مرتبط، از حالت بارگذاری خارج می‌شود. غیرفعال کردن این گزینه به‌ویژه برای واحدهای تایمر گذرا مفید است. توجه داشته باشید که این تنظیم هنگام راه‌اندازی مکرر یک واحد تایمر تأثیرگذار است: اگر RemainAfterElapse= روشن باشد، شروع تایمر برای بار دوم هیچ تأثیری نخواهد داشت. با این حال، اگر RemainAfterElapse= خاموش باشد و واحد تایمر از قبل از حالت بارگذاری خارج شده باشد، می‌توان آن را دوباره راه‌اندازی کرد و بنابراین سرویس می‌تواند چندین بار تحریک شود. مقدار پیش‌فرض true است.

در نسخه 229 اضافه شد.

برای تنظیمات بیشتر، systemd.unit(5)، systemd.exec(5) و systemd.kill(5) را بررسی کنید.

متغیرهای محیطی حاوی جزئیات مربوط به محرک برای واحدهای فعال‌شده تنظیم خواهند شد. برای جزئیات بیشتر، بخش "Environment Variables Set or Propagated by the Service Manager" در systemd.exec(5) را ببینید.

systemd(1), systemctl(1), systemd.unit(5), systemd.service(5), systemd.time(7), systemd.directives(7), systemd-system.conf(5), prctl(2)

systemd 261.2