欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

詳解推薦使用systemd?timer替代cronjob

 更新時間：2023年04月06日 14:28:32   作者：東風(fēng)微鳴  
這篇文章主要為大家介紹了推薦使用systemd?timer替代0cronjob原理分析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

概述

前幾天在使用 Terraform + cloud-init 批量初始化我的實(shí)驗(yàn)室 Linux 機(jī)器。正好發(fā)現(xiàn)有一些定時場景需要使用到 cronjob, 進(jìn)一步了解到 systemd timer 完全可以替換 cronjob, 并且 systemd timer 有一些非常有趣的功能。

回歸話題：為什么我推薦你使用 systemd timer 替代 cronjob? 因?yàn)橄啾?cronjob, systemd timer 有這些優(yōu)勢：

  • 可以覆蓋 cronjob 的所有功能
  • 統(tǒng)一日志收集到 systemd 日志
  • 針對時間精確度更詳細(xì)的配置項(xiàng)
  • 除了定時場景，還支持基于 event 的觸發(fā)
  • 相比 cronjob 更靈活的語法
  • 更豐富的使用/運(yùn)維命令集

接下來我們一一介紹。

首先我們通過系統(tǒng)自帶的 timer 來熟悉這個新玩意。

系統(tǒng)自帶的 timer

當(dāng) Ubuntu 或任何基于 systemd 的發(fā)行版安裝在一個新系統(tǒng)上時，它會創(chuàng)建幾個 timer，作為任何 Linux 主機(jī)后臺的系統(tǒng)維護(hù)程序的一部分。這些 timer 會觸發(fā)普通維護(hù)任務(wù)所需的事件，比如更新系統(tǒng)數(shù)據(jù)庫、清理臨時目錄、切割日志文件等等。

我們使用systemctl status *timer命令列出我的主機(jī)上的所有 timer:

casey@casey-Virtual-Machine:~$ systemctl status *timer
● plocate-updatedb.timer - Update the plocate database daily
     Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2023-04-04 16:49:49 CST; 19s ago
    Trigger: Wed 2023-04-05 00:40:16 CST; 7h left
   Triggers: ● plocate-updatedb.service
4 月 04 16:49:49 casey-Virtual-Machine systemd[1]: Started Update the plocate database daily.
● fwupd-refresh.timer - Refresh fwupd metadata regularly
     Loaded: loaded (/lib/systemd/system/fwupd-refresh.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2023-04-04 16:49:49 CST; 19s ago
    Trigger: Wed 2023-04-05 01:54:51 CST; 9h left
   Triggers: ● fwupd-refresh.service
4 月 04 16:49:49 casey-Virtual-Machine systemd[1]: Started Refresh fwupd metadata regularly.
● update-notifier-motd.timer - Check to see whether there is a new version of Ubuntu available
     Loaded: loaded (/lib/systemd/system/update-notifier-motd.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2023-04-04 16:49:50 CST; 19s ago
    Trigger: Sat 2023-04-08 03:19:02 CST; 3 days left
   Triggers: ● update-notifier-motd.service
4 月 04 16:49:50 casey-Virtual-Machine systemd[1]: Started Check to see whether there is a new version of Ubuntu available.
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2023-04-04 16:49:49 CST; 19s ago
    Trigger: Tue 2023-04-04 17:58:23 CST; 1h 8min left
   Triggers: ● fstrim.service
       Docs: man:fstrim
4 月 04 16:49:49 casey-Virtual-Machine systemd[1]: Started Discard unused blocks once a week.
...

每個 timer 至少有六行信息與之相關(guān)：

  • 第一行是 timer 的文件名和對其用途的簡短描述。
  • 第二行顯示 timer 的狀態(tài)，它是否被加載，timer unit 文件的完整路徑，以及供應(yīng)商的預(yù)設(shè)。
  • 第三行顯示其活動狀態(tài)，包括 timer 開始活動的日期和時間。
  • 第四行包含 timer 下次被觸發(fā)的日期和時間，以及直到觸發(fā)發(fā)生的大致時間。
  • 第五行顯示由 timer 觸發(fā)的事件或服務(wù)的名稱。
  • 一些（但不是全部）systemd unit 文件有指向相關(guān)文檔的指針。如上面的 Docs: man:fstrim
  • 最后一行是 timer 所觸發(fā)的服務(wù)的最新實(shí)例的日志條目。

創(chuàng)建 timer

優(yōu)勢之一：統(tǒng)一日志收集到 systemd 日志

為了更快了解 timer, 我們創(chuàng)建自己的 service unit 和 timer unit 來觸發(fā)。

具體用途為：每周定期更新 tailscale 的版本。

首先，創(chuàng)建 tailscale update 服務(wù)，如下：

[Unit]
Description=Tailscale update
Wants=tailscale-weekly-update.timer
[Service]
Type=oneshot
ExecStart=/usr/bin/tailscale update -yes
[Install]
WantedBy=multi-user.target

然后，創(chuàng)建 tailscale update timer, 如下：

[Unit]
Description=Tailscale update
Requires=tailscale-weekly-update.service
[Timer]
Unit=tailscale-weekly-update.service
OnCalendar=weekly
[Install]
WantedBy=timers.target

最后，啟用 timer:

systemctl enable tailscale-weekly-update.timer

這樣就可以了，但是為了演示，執(zhí)行：systemctl start tailscale-weekly-update.service 手動運(yùn)行一次。

輸出會直接集成到 systemd 日志里，并可以通過 journalctl 查看：（包含手動執(zhí)行日志，和后續(xù)自動定期執(zhí)行的日志）

$ sudo journalctl -S "2023-03-29 00:00:00" -u tailscale-weekly-update.service
4 月 02 09:14:28 casey-Virtual-Machine systemd[1]: Starting Tailscale node agent...
4 月 02 09:14:30 casey-Virtual-Machine tailscale[6898]: 獲?。? https://pkgs.tailscale.com/stable/ubuntu jammy InRelease
4 月 02 09:14:30 casey-Virtual-Machine tailscale[6898]: 獲?。? https://pkgs.tailscale.com/stable/ubuntu jammy/main amd64 Packages [7,853 B]
4 月 02 09:14:32 casey-Virtual-Machine tailscale[6898]: 已下載 13.9 kB，耗時 1 秒 (14.4 kB/s)
4 月 02 09:14:32 casey-Virtual-Machine tailscale[6898]: 正在讀取軟件包列表。..
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: 正在讀取軟件包列表。..
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: 正在分析軟件包的依賴關(guān)系樹。..
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: 正在讀取狀態(tài)信息。..
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]: 下列軟件包將被升級：
4 月 02 09:14:33 casey-Virtual-Machine tailscale[7101]:   tailscale
4 月 02 09:14:34 casey-Virtual-Machine tailscale[7101]: 升級了 1 個軟件包，新安裝了 0 個軟件包，要卸載 0 個軟件包，有 4 個軟件包未被升級。
4 月 02 09:14:34 casey-Virtual-Machine tailscale[7101]: 需要下載 23.0 MB 的歸檔。
4 月 02 09:14:34 casey-Virtual-Machine tailscale[7101]: 解壓縮后將會空出 1,024 B 的空間。
4 月 02 09:14:34 casey-Virtual-Machine tailscale[7101]: 獲取：1 https://pkgs.tailscale.com/stable/ubuntu jammy/main amd64 tailscale amd64 1.38.3 [23.0 MB]
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: 無法初始化前端界面：Dialog
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: （系統(tǒng)未設(shè)定 TERM 環(huán)境變量，所以對話框界面將不可使用。)
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: 返回前端界面：Readline
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: 無法初始化前端界面：Readline
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: （這個界面要求可控制的 tty。)
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: debconf: 返回前端界面：Teletype
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7115]: dpkg-preconfigure: 重新開啟標(biāo)準(zhǔn)輸入失敗：
4 月 02 09:15:13 casey-Virtual-Machine tailscale[7101]: 已下載 23.0 MB，耗時 40 秒 (577 kB/s)
4 月 02 09:15:14 casey-Virtual-Machine tailscale[7101]: [729B blob data]
4 月 02 09:15:14 casey-Virtual-Machine tailscale[7101]: 準(zhǔn)備解壓 .../tailscale_1.38.3_amd64.deb  ...
4 月 02 09:15:14 casey-Virtual-Machine tailscale[7101]: 正在解壓 tailscale (1.38.3) 并覆蓋 (1.38.2) ...
4 月 02 09:15:15 casey-Virtual-Machine tailscale[7101]: 正在設(shè)置 tailscale (1.38.3) ...
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: Running kernel seems to be up-to-date.
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: Services to be restarted:
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]:  systemctl restart tailscale-weekly-update.service
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: No containers need to be restarted.
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: No user sessions are running outdated binaries.
4 月 02 09:15:23 casey-Virtual-Machine tailscale[7325]: No VM guests are running outdated hypervisor (qemu) binaries on this host.
4 月 02 09:15:24 casey-Virtual-Machine systemd[1]: tailscale-weekly-update.service: Deactivated successfully.
4 月 02 09:15:24 casey-Virtual-Machine systemd[1]: Finished Tailscale node agent.
4 月 02 09:15:24 casey-Virtual-Machine systemd[1]: tailscale-weekly-update.service: Consumed 6.317s CPU time.
$ sudo journalctl -S "2023-03-29 00:00:00" -u tailscale-weekly-update.timer
4 月 02 09:14:28 casey-Virtual-Machine systemd[1]: Started Tailscale node agent.
4 月 02 20:01:52 casey-Virtual-Machine systemd[1]: tailscale-weekly-update.timer: Deactivated successfully.
4 月 02 20:01:52 casey-Virtual-Machine systemd[1]: Stopped Tailscale node agent.

如上面的日志，可以很方便地檢查 timer 和服務(wù)的狀態(tài)。

在日志這方面，你不需要做任何特別的事情，就可以使tailscale-weekly-update.service unit 中的ExecStart觸發(fā)器的STDOUT存儲在日志中。這都是使用 systemd 運(yùn)行服務(wù)的一部分。

Systemd timer 時間精度

優(yōu)勢之一：針對時間精確度更詳細(xì)的配置項(xiàng)

從上面日志，如果細(xì)看，timer 不會在:00秒的時候準(zhǔn)確觸發(fā)，甚至不會在上一個實(shí)例的一分鐘內(nèi)準(zhǔn)確觸發(fā)。這是故意的，但如果有必要的話，可以覆蓋它的默認(rèn)配置。

這種行為的原因是為了防止多個服務(wù)在完全相同的時間被觸發(fā)。例如，你可以使用時間規(guī)格，如每周、每天，等等。這些快捷方式都被定義為在它們被觸發(fā)的那一天的 00:00:00 時觸發(fā)。當(dāng)多個 timer 被這樣指定時，它們很有可能會試圖同時啟動。

systemd timer 被有意設(shè)計(jì)成在指定時間內(nèi)隨機(jī)觸發(fā)，以防止同時觸發(fā)。它們在一個時間窗口內(nèi)半隨機(jī)地觸發(fā)。根據(jù)systemd.timer手冊，這個觸發(fā)時間相對于所有其他定義的 timer 單位來說，保持在一個穩(wěn)定的位置。

大多數(shù)時候，這種概率性的觸發(fā)時間是沒有問題的。當(dāng)安排備份等任務(wù)運(yùn)行時，只要它們在非工作時間運(yùn)行，就不會有問題。一個系統(tǒng)管理員可以選擇一個確定的開始時間，如典型的 cronjob 規(guī)范中的 01:05:00，以不與其他任務(wù)沖突，但有很大范圍的時間值可以達(dá)到這個目的。啟動時間中的一分鐘隨機(jī)性通常是不相關(guān)的。

然而，對于某些任務(wù)，精確的觸發(fā)時間是一個絕對要求。對于這些任務(wù)，你可以通過在 timer unit 文件的 Timer 部分添加這樣的配置來指定更高的觸發(fā)時間跨度精度（如精度在一微秒內(nèi)）：

AccuracySec=1us

時間跨度可用于指定所需的精度，以及為重復(fù)性或一次性事件定義時間跨度。它可以識別以下單位：

  • usec, us, µs
  • msec, ms
  • seconds, second, sec, s
  • minutes, minute, min, m
  • hours, hour, hr, h
  • days, day, d
  • weeks, week, w
  • months, month, M （定義為 30.44 天）
  • years, year, y （定義為 365.25 天）

/usr/lib/systemd/system中的所有默認(rèn) timer 都指定了一個更大的精度范圍，因?yàn)榫_的時間并不關(guān)鍵?？纯聪到y(tǒng)創(chuàng)建的 timer 中的一些規(guī)格：

$ grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/plocate-updatedb.timer:AccuracySec=20min
/usr/lib/systemd/system/snapd.snap-repair.timer:AccuracySec=10min

Timer 類型

優(yōu)勢之一：除了定時場景，還支持基于 event 的觸發(fā)

systemd timer 具有 cron 所不具備的其他功能，cron 只在特定的、重復(fù)的、實(shí)時的日期和時間觸發(fā)。但是，一個 timer 可以被配置為在系統(tǒng)啟動后，或在啟動后，或在某個定義的服務(wù) unit 激活后的特定時間內(nèi)觸發(fā)。這些被稱為單調(diào)性 timer。單調(diào)指的是一個持續(xù)增加的計(jì)數(shù)或序列。這些 timer 不是持久的，因?yàn)樗鼈冊诿看螁雍蠖紩刂谩?/p>

表 1 列出了單調(diào)的 timer 以及每個 timer 的簡短定義，還有 "OnCalendar" timer，它不是單調(diào)的，用于指定未來的時間，可能是重復(fù)的，也可能不是。

Timer單調(diào)性定義
OnActiveSec=X這定義了一個相對于 timer 被激活的時刻的 timer。
OnBootSec=X這定義了一個相對于機(jī)器啟動時間的 timer。
OnStartupSec=X這定義了一個相對于服務(wù)管理器首次啟動時間的計(jì)時器。對于系統(tǒng) timer unit，這與OnBootSec=非常相似，因?yàn)橄到y(tǒng)服務(wù)管理器通常在啟動時很早就啟動。當(dāng)配置在每個用戶服務(wù)管理器中運(yùn)行的單元時，它主要是有用的，因?yàn)橛脩舴?wù)管理器一般只在第一次登錄時啟動，而不是在啟動時。
OnUnitActiveSec=X這定義了一個相對于要激活的 timer 最后一次被激活的時間。
OnUnitInactiveSec=X這定義了一個相對于要激活的 timer 最后被停用的時間的定時器。
OnCalendar=這就用日歷事件表達(dá)式定義了實(shí)時 timer。更多關(guān)于日歷事件表達(dá)式的語法信息請參見systemd.time(7)。否則，其語義與OnActiveSec=及相關(guān)設(shè)置類似。這個 timer 是最像那些與 cron 服務(wù)一起使用的 timer。

表 1: systemd timer 定義

單調(diào) timer 的時間跨度可以使用與前面提到的AccuracySec語句相同的快捷名稱，但 systemd 將這些名稱規(guī)范化為秒。例如，你可能想指定一個 timer，在系統(tǒng)啟動 5 天后觸發(fā)一次事件，可以這樣寫： OnBootSec=5d。如果主機(jī)在2020-06-15 09:45:27啟動，timer 將在2020-06-20 09:45:27或之后一分鐘內(nèi)觸發(fā)。

Calendar event 定義

優(yōu)勢之一：相比 cronjob 更靈活的語法

Calendar event 定義是在所需的重復(fù)時間觸發(fā) timer 的關(guān)鍵部分。首先看一下OnCalendar設(shè)置中使用的一些規(guī)格。

systemd 及其 timer 使用的時間和日期規(guī)格與 crontab 中使用的格式不同。它比 crontab 更靈活，允許以at命令的方式模糊日期和時間。

使用OnCalendar=的 systemdtimer 的基本格式是DOW YYYY-MM-DD HH：MM：SS。DOW（星期）是可選的，其他字段可以使用星號（*）來匹配該位置的任何值。所有日歷時間形式都被轉(zhuǎn)換為規(guī)范化的形式。如果沒有指定時間，則假定其為 00:00:00。如果沒有指定日期但指定了時間，那么下一個匹配可能是今天或明天，這取決于當(dāng)前的時間。名稱或數(shù)字可用于月份和星期?？梢灾付總€單位的逗號分隔的列表。單位范圍可以在開始和結(jié)束值之間用...來指定。

有幾個有趣的選項(xiàng)用于指定日期。波浪號（~）可以用來指定該月的最后一天或該月最后一天之前的指定天數(shù)。"/"可以用來指定一周中的某一天作為修飾語。

下面是一些在OnCalendar語句中使用的典型時間規(guī)格的例子：

Calendar event 定義描述
DOW YYYY-MM-DD HH:MM:SS
*-*-* 00:15:30每年的每個月的每一天，在午夜后的 15 分鐘 30 秒。
Weekly每個星期一的 00:00:00
Mon *-*-* 00:00:00與每周相同
Mon與每周相同
Wed 2020-*-*2020 年的每個星期三，00:00:00
Mon..Fri 2021-*-*2021 年的每個工作日的 00:00:00
2023-6,7,8-1,15 01:15:002023 年 6 月、7 月和 8 月的 1 日和 15 日凌晨 01:15:00
Mon *-05~03任何一年的 5 月的下一個星期一，也是月末的第三天。
Mon..Fri *-08~04任何年份的 8 月底前的第 4 天，如果該天也是工作日，則為 8 月底。
*-05~03/2從五月底開始的第三天，兩天后再來一次。每年都會重復(fù)。請注意，這個表達(dá)式使用了（~）。
*-05-03/2五月的第三天，然后在五月的其余時間里每隔一天。每年重復(fù)一次。注意，這個表達(dá)式使用了破折號（-）。

表 2: 示例OnCalendar event 定義

測試 calendar 定義

優(yōu)勢之一：更豐富的使用/運(yùn)維命令集

systemd 提供了一個很好的工具來驗(yàn)證和檢查 timer 中的日歷時間事件規(guī)范。systemd-analyze calendar工具解析了一個日歷時間事件規(guī)范，并提供了規(guī)范化的形式以及其他有趣的信息，比如下一個 "elapse"（即匹配）的日期和時間，以及達(dá)到觸發(fā)時間前的大致時間。

首先，看一下未來的一個沒有時間的日期：

$ systemd-analyze calendar 2030-06-17
  Original form: 2030-06-17
Normalized form: 2030-06-17 00:00:00
    Next elapse: Mon 2030-06-17 00:00:00 CST
       (in UTC): Sun 2030-06-16 16:00:00 UTC
       From now: 7 years 2 months left

現(xiàn)在添加一個時間。在這個例子中，日期和時間作為非相關(guān)實(shí)體被單獨(dú)分析：

$ systemd-analyze calendar 2030-06-17 15:21:16
  Original form: 2030-06-17
Normalized form: 2030-06-17 00:00:00
    Next elapse: Mon 2030-06-17 00:00:00 CST
       (in UTC): Sun 2030-06-16 16:00:00 UTC
       From now: 7 years 2 months left
  Original form: 15:21:16
Normalized form: *-*-* 15:21:16
    Next elapse: Wed 2023-04-05 15:21:16 CST
       (in UTC): Wed 2023-04-05 07:21:16 UTC
       From now: 21h left

要把日期和時間作為一個 unit 來分析，需要用引號把它們括起來。

$ systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16
    Next elapse: Mon 2030-06-17 15:21:16 CST
       (in UTC): Mon 2030-06-17 07:21:16 UTC
       From now: 7 years 2 months left

現(xiàn)在測試表 2 中的條目。選一個復(fù)雜的：

$ systemd-analyze calendar "2023-6,7,8-1,15 01:15:00"
  Original form: 2023-6,7,8-1,15 01:15:00
Normalized form: 2023-06,07,08-01,15 01:15:00
    Next elapse: Thu 2023-06-01 01:15:00 CST
       (in UTC): Wed 2023-05-31 17:15:00 UTC
       From now: 1 month 26 days left

讓我們看一個例子，在這個例子中，我們列出了時間戳表達(dá)式的下五個執(zhí)行時間：

$ systemd-analyze calendar --iterations=5 "Mon *-05~3"
  Original form: Mon *-05~3
Normalized form: Mon *-05~03 00:00:00
    Next elapse: Mon 2023-05-29 00:00:00 CST
       (in UTC): Sun 2023-05-28 16:00:00 UTC
       From now: 1 month 23 days left
       Iter. #2: Mon 2028-05-29 00:00:00 CST
       (in UTC): Sun 2028-05-28 16:00:00 UTC
       From now: 5 years 1 month left
       Iter. #3: Mon 2034-05-29 00:00:00 CST
       (in UTC): Sun 2034-05-28 16:00:00 UTC
       From now: 11 years 1 month left
       Iter. #4: Mon 2045-05-29 00:00:00 CST
       (in UTC): Sun 2045-05-28 16:00:00 UTC
       From now: 22 years 1 month left
       Iter. #5: Mon 2051-05-29 00:00:00 CST
       (in UTC): Sun 2051-05-28 16:00:00 UTC
       From now: 28 years 1 month left

這應(yīng)該給你足夠的信息來開始測試你的OnCalendar時間規(guī)格。

總結(jié)

systemd timer 可以用來執(zhí)行與 cron 工具相同類型的任務(wù)，但在觸發(fā)事件的 calendar 和單調(diào)的時間規(guī)格方面提供了更多的靈活性。

除此之外，systemd timer 還有的優(yōu)勢包括：

  • 統(tǒng)一日志收集到 systemd 日志
  • 針對時間精確度更詳細(xì)的配置項(xiàng)
  • 更豐富的使用/運(yùn)維命令集

快去嘗試遷移你的 cronjob 到 systemd timer 吧~??????

參考資料

以上就是推薦使用systemd timer替代0cronjob的詳細(xì)內(nèi)容，更多關(guān)于systemd timer替代cronjob的資料請關(guān)注腳本之家其它相關(guān)文章！

相關(guān)文章

最新評論