systemctl 持久計時器和服務，當電腦關閉時
當電腦在給定的觸發時間關閉時，systemctl 計時器如何工作？有選項“
Persistent”，但是該命令究竟是什麼時候執行的呢？在多大程度上保證命令將被安全執行，例如，在兩次執行之間不得經過最大給定時間？地位：
$ systemctl status mintupdate-automation-upgrade.timer ● mintupdate-automation-upgrade.timer - Update Manager automatic upgrades Loaded: loaded (/lib/systemd/system/mintupdate-automation-upgrade.timer; enabled; vendor preset: enabled) Active: active (waiting) since Fri 2021-01-22 20:20:24 CET; 4 days ago Trigger: Thu 2021-01-28 00:44:21 CET; 12h left Triggers: ● mintupdate-automation-upgrade.service配置文件
$ systemctl cat mintupdate-automation-upgrade.* # /lib/systemd/system/mintupdate-automation-upgrade.timer [Unit] Description=Update Manager automatic upgrades [Timer] OnCalendar=daily OnStartupSec=60m RandomizedDelaySec=60m Persistent=true [Install] WantedBy=timers.target # /lib/systemd/system/mintupdate-automation-upgrade.service [Unit] Description=Update Manager automatic upgrades After=network-online.target [Service] Type=oneshot CPUQuota=50% CPUWeight=20 IOWeight=20 ExecStart=/usr/lib/linuxmint/mintUpdate/automatic_upgrades.py [Install] WantedBy=multi-user.target計時器有 Persistent 標誌，但服務（由計時器觸發）沒有
$ systemctl show mintupdate-automation-upgrade.timer --property=Persistent Persistent=yes
它似乎不起作用，當電腦關閉或沒有網際網路連接時，它不會趕上，因為消息仍然說：
$ systemctl --no-pager status mintupdate-automation-upgrade.timer ... Trigger: Tue 2021-02-02 00:32:40 CET; 13h left所以更新過程（至少使用這種方法，可能與此相反
unattended-upgrades）並不是很安全。如果有可能修復它，請告訴我？
Persistent=僅適用於計時器（請參閱 參考資料man systemd.timer）。這就是為什麼你看不到它systemctl show mintupdate-automation-upgrade.service --property=Persistent當我們查看計時器時，它會說：
[Timer] OnCalendar=daily OnStartupSec=60m RandomizedDelaySec=60m Persistent=true
OnCalendar=daily：定義帶有日曆事件表達式的實時（即掛鐘）計時器daily。這實際上意味著它將在每晚午夜執行。Persistent=true: 表示“服務單元最後一次觸發的時間儲存在磁碟上。當定時器被啟動時，如果在定時器不活動期間至少被觸發一次，則立即觸發服務單元。這樣的觸發是儘管如此，仍會受到 RandomizedDelaySec= 施加的延遲的影響。這對於在系統關閉時趕上錯過的服務執行非常有用。OnStartupSec=60m定義一個與服務管理器首次啟動時間相關的計時器。RandomizedDelaySec=60m將計時器延遲隨機選擇的、均勻分佈的時間量（介於 0 到 60m 之間）。每個計時器單元將在每次迭代之前隨機確定此延遲，並且延遲將簡單地添加到下一個確定的經過時間之上。此設置對於在特定時間間隔內擴展類似配置的計時器事件的調度很有用，以防止它們同時觸發，從而可能導致資源擁塞。因此，如果您讓您的機器過夜，它會在午夜和凌晨 01 點之間啟動。如果您重新啟動機器，它將在啟動後 1 到 2 小時內觸發。如果您在一夜之間關閉機器，那麼在早上它會在啟動後 1 小時內觸發（對於
OnCalendar/Persistent觸發器），然後在啟動後 1 到 2 小時內觸發（對於OnStartupSec觸發器）。我懷疑您最擔心的是您在 23 點啟動機器時的情況。在這種情況下，它將在 00h00 和 01h00 之間觸發兩次。
oneshot當觸發器觸發時，如果服務仍然處於執行activating狀態，它將被忽略ExecStart=。因此，您不會有同一服務的兩個並發觸發器，因此它是安全的。但是隨後您詢問兩次執行之間的最短時間。我們通常盡量不要用“時間”來保證事情的安全。這類似於添加
sleepbash 腳本，當我們懶得監聽適當的信號 (./foo & sleep 5 && ./bar) 時，這通常是一種解決方法。它也是易變的，因為不能保證在時間到期時事情會真正準備好。如果這個腳本寫得好，它應該連續執行幾次，不需要任何時間分隔它（./foo && ./foo && ./foo），所以你不必擔心安全性。