👩‍🚀 📍 🏣 cronジョブの代わりにsystemdタイマーを使用する 🧔🏻 😃 🙌

現在、cronジョブをsystemdタイマーに置き換える作業を行っています。私は数年前からタイマーを使用していますが、通常、タイマーの使用の微妙な点については深く掘り下げず、関心のあるタスクを完了するために必要なものだけを理解していました。私は最近、systemdに関する一連の記事に取り組み、systemdタイマーにはいくつかの非常に興味深い機能があることを発見しました。

これらのタイマーは、cronジョブと同様に、特定の時間に、システムでさまざまなアクションをトリガーできます。例-シェルスクリプトまたはプログラムの実行。タイマーは、たとえば1日1回、月曜日にのみ機能します。もう1つの例は、営業時間中（午前8時から午後6時まで）に15分ごとに起動するタイマーです。しかし、systemdタイマーは、cronジョブでは実行できないことを実行できます。たとえば、タイマーは、イベント後の指定された時間にスクリプトを呼び出したり、プログラムをプログラムしたりできます。このようなイベントは、システムの起動またはsystemdの起動、前のタスクの完了、または以前にタイマーによって呼び出されたサービスの終了である可能性があります。

システムメンテナンスに使用されるタイマー

Fedoraまたは別のsystemdベースのLinuxディストリビューションがコンピューターにインストールされると、システムのメンテナンスルーチンの一部としていくつかのタイマーが作成されます。これらの手順は、すべてのLinuxシステムで自動的に実行されます。対応するタイマーは、システムデータベースの更新、一時ディレクトリのクリア、ログファイルのローテーションなど、さまざまなサービスタスクをトリガーします。

例として、実験に使用した仮想マシンで使用できるタイマーに関する情報をここに示します。ここでは、すべてのタイマーのリストを取得するために、コマンドを使用しましたsystemctl status *timer..。アスタリスクのワイルドカードは、他の同様のコマンドと同じ役割を果たします。つまり、systemdのすべてのタイマー（タイマーユニット、「タイマーユニットファイル」または「タイマーユニット」とも呼ばれます）に関心があることをシステムに通知します。

[root@testvm1 ~]# systemctl status *timer
● mlocate-updatedb.timer - Updates mlocate database every day
     Loaded: loaded (/usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● mlocate-updatedb.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Updates mlocate database every day.

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily rotation of log files.

● sysstat-summary.timer - Generate summary of yesterday's process accounting
     Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left
   Triggers: ● sysstat-summary.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Generate summary of yesterday's process accounting.

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Discard unused blocks once a week.

● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
     Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left
   Triggers: ● sysstat-collect.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Run system activity accounting tool every 10 minutes.

● dnf-makecache.timer - dnf makecache --timer
     Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left
   Triggers: ● dnf-makecache.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started dnf makecache –timer.

● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
     Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 08:19:00 EDT; 23h left
   Triggers: ● systemd-tmpfiles-clean.service
       Docs: man:tmpfiles.d(5)
             man:systemd-tmpfiles(8)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily Cleanup of Temporary Directories.

各タイマーは、それに関する情報を含む少なくとも6行に関連付けられています。

最初の行には、タイマーファイルの名前と、タイマーが存在する目的の簡単な説明が含まれています。
2行目には、タイマーの状態に関する情報が表示されます。つまり、ロードされているかどうかを報告し、タイマーファイルへのフルパスを示し、ベンダープリセットの状態（無効または有効）を示します。
3行目には、タイマーのアクティビティに関する情報が表示されます。これには、タイマーがいつアクティブ化されたかに関する情報が含まれます。
4行目には、タイマーの次の開始の日付と時刻、およびタイマーが開始するまでの残りのおおよその時間が含まれています。
5行目は、タイマーによって呼び出されたサービスまたはイベントの名前を示しています。
一部の（すべてではありませんが）systemdタイマーユニットファイルには、ドキュメントへのポインタが含まれています。このようなポインタは、私の例では、3つのタイマーの説明にあります。
タイマーの説明の最後の行は、タイマーによって呼び出されたサービスの最新のインスタンスに関連付けられているログエントリです。

コンピューターsystemctl status *timerでコマンドを実行しようとすると、表示されるタイマーのセットが私のものとはかなり異なる場合があります。

タイマーの作成

既存のタイマーを分析することでタイマーの動作の詳細を理解できますが、独自のサービスユニットファイル（サービス構成ファイル、サービスユニット）と、対応するサービスが呼び出されるタイマーファイルを作成することをお勧めします。私たちはここにいます、話を複雑にしないために、かなり些細な例を挙げてください。しかし、私たちがそれに対処した後は、他のタイマーの動作を理解しやすくなります。

まず、コマンドのような単純なものを実行する単純なサービス構成ファイルを作成しましょうfree。たとえば、空きメモリの量を定期的に監視する必要がある場合に、これが必要になることがあります。myMonitor.serviceフォルダ内にという名前のユニットファイルを作成しましょう/etc/systemd/system。実行可能である必要はありません。

# This service unit is for testing timer units
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs system statistics to the systemd journal
Wants=myMonitor.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/free

[Install]
WantedBy=multi-user.target

このファイルは、おそらく最も単純なサービス構成ファイルです。それでは、ステータスをチェックしてテストし、期待どおりに機能することを確認しましょう。

[root@testvm1 system]# systemctl status myMonitor.service
● myMonitor.service - Logs system statistics to the systemd journal
     Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
[root@testvm1 system]# systemctl start myMonitor.service
[root@testvm1 system]#

コンソールに何も出力されないのはなぜですか？これは、デフォルトで、stdoutサービスユニットファイルを使用してsystemdによって開始されたプログラムからの標準出力（）がsystemdログにリダイレクトされるためです。このため、少なくとも対応するレコードが存在する限り、これらのレコードを分析できます。ログを見て、私たちのサービスと私たちがテストした日に関連するエントリを探しましょう。対応するコマンドは次のようになります: journalctl -S today -u myMonitor.service。キー-Sは短縮バージョン--sinceです。ユーティリティを使用する期間を指定できますjournalctlレコードを探しています。重要なのは、以前の結果に関心がないということではありません。私たちの場合、そのような結果は単にそうではありません。このキーは、ユーティリティがデータを検索するために必要な時間を短縮するために使用されます。コンピュータが長時間動作していると、ログに多くのエントリが蓄積される可能性があります。

[root@testvm1 system]# journalctl -S today -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. --
Jun 11 09:12:09 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 09:12:09 testvm1.both.org free[377966]:               total        used        free      shared  buff/cache   available
Jun 11 09:12:09 testvm1.both.org free[377966]: Mem:       12635740      522868    11032860        8016     1080012    11821508
Jun 11 09:12:09 testvm1.both.org free[377966]: Swap:       8388604           0     8388604
Jun 11 09:12:09 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
[root@testvm1 system]#

サービス構成ファイルを使用して起動されるタスクは、単一のプログラム、一連のプログラム、または任意のスクリプト言語で記述されたスクリプトとして表すことができます。myMonitor.serviceセクションの最後に[Service]次のような別のタスクをユニットファイルに追加しましょう。

ExecStart=/usr/bin/lsblk

サービスを再開して、ログを確認してみましょう。以下に示すものに似たものがそこにあるはずです。つまり、ログには両方のコマンドによって出力されたデータが含まれている必要があります。

Jun 11 15:42:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 15:42:18 testvm1.both.org free[379961]:               total        used        free      shared  buff/cache   available
Jun 11 15:42:18 testvm1.both.org free[379961]: Mem:       12635740      531788    11019540        8024     1084412    11812272
Jun 11 15:42:18 testvm1.both.org free[379961]: Swap:       8388604           0     8388604
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sda             8:0    0  120G  0 disk
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─sda1          8:1    0    4G  0 part /boot
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─sda2          8:2    0  116G  0 part
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sr0            11:0    1 1024M  0 rom
Jun 11 15:42:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 11 15:42:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

ここで、すべてが正しく機能していることを確認し/etc/systemd/systemたら、フォルダー内にタイマーユニットファイルを作成して、名前を付けmyMonitor.timerます。以下をファイルに追加します。

# This timer unit is for testing
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs some system statistics to the systemd journal
Requires=myMonitor.service

[Timer]
Unit=myMonitor.service
OnCalendar=*-*-* *:*:00

[Install]
WantedBy=timers.target

OnCalendarこのファイルのタイムスタンプ*-*-* *:*:00により、タイマーはmyMonitor.service1分ごとにユニットを呼び出す必要があります。OnCalendarこれについては、以下で詳しく説明します。

それまでの間、タイマーサービスの開始に関連するログエントリを確認できます。タイマーウォッチモードをオンにすることもできます。ただし、サービスを監視すると、ほぼリアルタイムで結果を確認できます。これを行うにはjournalctl、キー-f（follow）を使用して実行する必要があります。

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --

タイマーを開始しますが、システム起動時の自動開始には含めないでください。

[root@testvm1 ~]# systemctl start myMonitor.timer
[root@testvm1 ~]#

しばらくの間何が起こるかを見てください。

結果の1つがすぐに表示されます。そして、次のものは約1分間隔で表示されます。雑誌を数分間見てください。

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Jun 13 08:39:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:39:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:39:19 testvm1.both.org free[630566]:               total        used        free      shared  buff/cache   available
Jun 13 08:39:19 testvm1.both.org free[630566]: Mem:       12635740      556604    10965516        8036     1113620    11785628
Jun 13 08:39:19 testvm1.both.org free[630566]: Swap:       8388604           0     8388604
Jun 13 08:39:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sda             8:0    0  120G  0 disk
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─sda2          8:2    0  116G  0 part
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:40:46 testvm1.both.org free[630572]:               total        used        free      shared  buff/cache   available
Jun 13 08:40:46 testvm1.both.org free[630572]: Mem:       12635740      555228    10966836        8036     1113676    11786996
Jun 13 08:40:46 testvm1.both.org free[630572]: Swap:       8388604           0     8388604
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sda             8:0    0  120G  0 disk
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─sda2          8:2    0  116G  0 part
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:40:46 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:41:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:41:46 testvm1.both.org free[630580]:               total        used        free      shared  buff/cache   available
Jun 13 08:41:46 testvm1.both.org free[630580]: Mem:       12635740      553488    10968564        8036     1113688    11788744
Jun 13 08:41:46 testvm1.both.org free[630580]: Swap:       8388604           0     8388604
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sda             8:0    0  120G  0 disk
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─sda2          8:2    0  116G  0 part
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sr0            11:0    1 1024M  0 rom
Jun 13 08:41:47 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:41:47 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

必ずタイマー状態とサービス状態の両方を確認してください。

ここで私が気づいたことに気づきましたか？雑誌を読んでいると、少なくとも2つのことに気づいたかもしれません。

まずExecStart、myMonitor.service書き込みのログを記録するために特別なことをする必要がないという事実stdout。この機能は、標準のsystemd起動機能の一部です。ただし、これは、サービス構成ファイルからスクリプトを実行するときは、スクリプトが書き込むデータの量に注意する必要があることを意味しますstdout。

第二に、タイマーが正確に開始しないことに気づいたかもしれません:00毎分の秒であり、最後の実行から正確に1分後でもありません。これは、このようなタイマーの機能の1つであり、必要な場合（または、システム管理者の気持ちを傷つける場合）、タイマーをより正確にすることで、タイマーのこの動作を変更できます。

タイマーが:00毎分の秒単位で開始しない理由は、システムが複数のサービスを同時に開始できないようにする傾向があるためです。時間インジケータを設定するときたとえば、OnCalendar次のような値を使用することができWeekly、Dailyそして他の人を。ある時点に名前を付けるこれらの簡単な方法は、それらが使用されるタイマーが開始するように構成されています。00:00:00対応する日。複数のタイマーがこのように構成されている場合、それらがすべて同時に起動する可能性が高くなります。

これが、systemdタイマーが、正確に指定された時間に開始するのではなく、ランダムに開始するように意図的に設計されている理由です。この逸脱は完全に偶然とは言えません。タイマーは、指定された瞬間に開始し、元の時間から1分で終了する時間ウィンドウのどこかで開始します。今回は、のドキュメントに従ってsystemd.timer、システムで宣言されている他のすべてのタイマーを考慮して、安定した状態に保たれます。上記のログフラグメントでは、タイマーが開始直後にトリガーされ、次の1分ごとの開始から約46秒または47秒後にトリガーされることがわかります。

ほとんどの場合、タイマーの正確なタイミングを決定するためのこのような確率論的アプローチは、すべての人に適しています。営業時間外に何かのバックアップコピーを作成するなどのタスクをスケジュールする場合、これは問題ではありません。 cronジョブを設定するシステム管理者は、01:05:00これらのジョブが他のジョブと競合しないようにするなど、明確に定義された開始時間を指定できます。これを可能にする時間を指定する方法は多岐にわたります。 1分を超えないタスクの開始時間のランダムな変更は、通常、特別な役割を果たしません。

ただし、一部のタスクでは、タイマーの正確なタイミングが非常に重要です。このような場合、タイマーを設定するときに、より正確な動作時間を指定できます（精度まではマイクロ秒単位で測定されます）。これは、セクションのタイマー記述ファイルにTimer、次のような構造を追加することによって行われます。

AccuracySec=1us

特別なキーワードを使用して、タイマーの必要な精度を指定できます。これらのキーワードは、定期的なイベントや1回限りのイベントを設定するときにも使用できます。システムは次のキーワードを理解します。

マイクロ秒：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は、トリガーの精度を設定するはるかに長い範囲を使用して構成されます。これらのタイマーの場合、厳密に指定された時間でのトリガーは特に重要ではないためです。システムで生成されたタイマーのいくつかの仕様を見てください。

[root@testvm1 system]# 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/logwatch.timer:AccuracySec=12h
/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h
/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h
/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h
[root@testvm1 system]#

ディレクトリからタイマーファイルの内部構造をよりよく理解するために、/usr/lib/systemd/systemそれらの内容を表示できます。

システムの起動時にアクティブになるように学習タイマーを構成する必要はありません。ただし、必要に応じて、次のコマンドを使用できます。

[root@testvm1 system]# systemctl enable myMonitor.timer

作成するタイマーファイルは、実行可能である必要はありません。さらに、サービス構成ファイルはタイマーによって呼び出されるため、起動時にアクティブ化されるように構成する必要はありません。必要に応じて、コマンドラインから手動でサービスを呼び出すこともできます。これを試して、systemdログを調べてください。

タイマーの精度、イベントのタイミングを指定する方法、およびイベントを発生させる方法の詳細については、systemd.timerおよびのドキュメントを参照してくださいsystemd.time。

タイマータイプ

Systemdタイマーには、cronジョブにはない他の機能があり、「1回限り」または繰り返し、リアルタイムおよびリアルタイムの日付でのみ呼び出されます。 Systemdタイマーは、他のsystemdユニットの状態の変化に基づいて呼び出されるように構成できます。たとえば、タイマーは、システムの起動後、ユーザーがログインした後、または特定のサービスをアクティブ化した後の指定された時間の後にトリガーされるように構成できます。これらのタイマーは単調と呼ばれます。これらのタイマーは、システムを再起動するたびにリセットされます。

次の表に、単調なタイマーのリストと、それぞれの簡単な説明を示します。タイマーの説明もあります。OnCalendar、単調ではなく、将来、1回限りまたは繰り返しの起動を計画する必要がある場合に使用されます。この表はドキュメントに基づいていますsystemd.timer。

タイマー	単調	説明
`OnActiveSec=`	バツ	タイマーの動作時間は、タイマーがアクティブになった瞬間を基準にして設定されます。
`OnBootSec=`	バツ	タイマーは、システムが起動した瞬間を基準にして設定されます。
`OnStartupSec=`	バツ	. `OnBootSec=`, . , , , , , .
`OnUnitActiveSec=`	X	, , , .
`OnUnitInactiveSec=`	X	, , , .
`OnCalendar=`		. `systemd.time(7)`. `OnActiveSec=`. — systemd, , cron.

単調なタイマーを設定する場合、上記で説明したのと同じキーワードを使用できますAccuracySec。ただし、systemdは対応する時間間隔を秒に変換することに注意してください。たとえば、システムの起動から5日後に1回起動するタイマーを設定できます。次のような説明のように見える場合がありますOnBootSec=5d。コンピューターがで起動さ2020-06-15れた09:45:27場合、タイマーは2020-06-20で09:45:27（またはこの時点から1分以内に）開始されます。

カレンダーイベントの説明

カレンダーイベントの適用は、定期的に呼び出されるタイマーを説明する上で重要な部分です。時間インジケーターを設定するときに使用されるこのようなイベントの機能のいくつかを調べてみましょうOnCalendar。

Systemdとそれに対応するタイマーは、crontabとは異なる日時形式を使用します。この形式は、crontabで使用される形式よりも柔軟性があります。コマンドスタイルで、簡単な方法で日付と時刻を指定できますat。それに精通している人にとってはat、systemdタイマーの設定を理解しやすいはずです。

使用した場合OnCalendar=のタイマーを設定するには、次の基本的なフォーマットは、日付と時刻を指定するために使用されます。

DOW YYYY-MM-DD HH:MM:SS

DOW（曜日）は、上記の構成のオプション部分です。他のフィールドでは、アスタリスク（*）記号を使用して、それが占める位置に表示される可能性のある任意の値を表すことができます。日付と時刻の表示のすべての形式は、正規化された形式に変換されます。時間が指定されていない場合は、と見なされます00:00:00。日付が指定されていないが時刻が指定されている場合、タイマーは開始日（比較的「今日」）または翌日（「明日」）のいずれかで機能します。現在の時刻によって異なります。月と曜日は、それらの名前を使用して名前を付けることができます。ここでは、コンマで区切られた値のリストを使用できます。…値の範囲は、範囲の開始値と終了値の間に3つのドット（）で区切ることができます。

日付を指定するとき、私たちは自由に使えるいくつかの興味深いオプションがあります。したがって、ティルデ（〜）を使用して、月の最終日を示したり、月の最終日の特定の日数前の日付を示したりすることができます。フォワードスラッシュ（/）は、曜日を示す修飾子として使用できます。

次の表は、式で使用されるタイミングのいくつかの典型的な例を示していますOnCalendar。

カレンダーイベントの提示例 `DOW YYYY-MM-DD HH:MM:SS`	説明
`--* 00:15:30`	毎年毎月の毎日、深夜から15分30秒後。
`Weekly`	毎週月曜日`00:00:00`。
`Mon --* 00:00:00`	と同じ`Weekly`。
`Mon`	と同じ`Weekly`。
`Wed 2020--`	2020年の毎週水曜日`00:00:00`。
`Mon..Fri 2021--`	2021年の平日`00:00:00`。
`2022-6,7,8-1,15 01:15:00`	2022年6月1日と15日、7月と8月の`01:15:00`深夜0時以降。
`Mon *-05~03`	, , , 3 .
`Mon..Fri *-08~04`	, 4 , .
`*-05~03/2`	3 , , — , . . , `~`.
`*-05-03/2`	, — . . , (`-`).

,

Systemdには、カレンダーイベントの仕様を確認および調査するための優れたツールがあります。systemd-analyze calendarカレンダーイベントの説明を解析し、正規化された形式で提示するチームについて話しています。このコマンドは、次のそのようなイベントの日付と時刻、その瞬間までの残りのおおよその時間など、他の興味深い情報も提供します。

まずは、日付のみが含まれている仕様、見てみる時間に関する情報が含まれていませんしましょう（分野における倍というノートNext elapseとは(in UTC)異なり、この違いは、ローカルタイムゾーンに依存します）：

[student@studentvm1 ~]$ 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 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

それでは、説明に時間情報を追加しましょう。この例では、日付と時刻は、相互に関連していないエンティティとして個別に分析されます。

[root@testvm1 system]# 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 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    

  Original form: 15:21:16                  
Normalized form: *-*-* 15:21:16            
    Next elapse: Mon 2020-06-15 15:21:16 EDT
       (in UTC): Mon 2020-06-15 19:21:16 UTC
       From now: 3h 55min left              
[root@testvm1 system]#

ここで、日付と時刻が一緒に考慮される例を考えてみましょう。これを行うには、それらを引用符で囲みます。ただし、でこのような構造を使用する場合はOnCalendar、引用符を削除することを忘れないでください。そうしないと、エラーが発生します。

[root@testvm1 system]# 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 EDT
       (in UTC): Mon 2030-06-17 19:21:16 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

それでは、前の表から何かを確認しましょう。私は特に彼女からのこの説明が好きです：

2022-6,7,8-1,15 01:15:00

それを分析しましょう：

[root@testvm1 system]# systemd-analyze calendar "2022-6,7,8-1,15 01:15:00"
  Original form: 2022-6,7,8-1,15 01:15:00
Normalized form: 2022-06,07,08-01,15 01:15:00
    Next elapse: Wed 2022-06-01 01:15:00 EDT
       (in UTC): Wed 2022-06-01 05:15:00 UTC
       From now: 1 years 11 months left
[root@testvm1 system]#

次に説明を見てみましょうMon *-05~3。ただし、今回は、次の設定を使用して、タイマーの次の5回に関する情報をプログラムに要求します。

[root@testvm1 ~]# 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 EDT
       (in UTC): Mon 2023-05-29 04:00:00 UTC
       From now: 2 years 11 months left    
       Iter. #2: Mon 2028-05-29 00:00:00 EDT
       (in UTC): Mon 2028-05-29 04:00:00 UTC
       From now: 7 years 11 months left    
       Iter. #3: Mon 2034-05-29 00:00:00 EDT
       (in UTC): Mon 2034-05-29 04:00:00 UTC
       From now: 13 years 11 months left    
       Iter. #4: Mon 2045-05-29 00:00:00 EDT
       (in UTC): Mon 2045-05-29 04:00:00 UTC
       From now: 24 years 11 months left    
       Iter. #5: Mon 2051-05-29 00:00:00 EDT
       (in UTC): Mon 2051-05-29 04:00:00 UTC
       From now: 30 years 11 months left    
[root@testvm1 ~]#

systemd-analyze calendar独自のカレンダーイベント定義のテストを開始するのに十分なユースケースをカバーしたと思います。このツールにsystemd-analyzeは他にも興味深い機能があることに注意してください。

追加資料

インターネット上のsystemdには多くの出版物がありますが、ほとんどの場合、短すぎたり、非常に単純だったり、バグがあったりします。この記事は、systemdに関するいくつかの優れた情報源を提供します。以下は、このトピックに関するいくつかのより高品質の資料へのリンクのリストです。

Fedoraプロジェクトによるsystemdの実用ガイド。
従来のSystemVコマンドとsystemdコマンドをマップするFedoraプロジェクトのチートシート。
systemdとそれが作成された理由の詳細。
systemd専用の情報とアドバイスを含む資料。
(Lennart Poettering), systemd. , 2010 2011, . systemd .
systemd.
systemd.

Systemdタイマーを使用して、cronジョブと同じタスクを実行できます。ただし、systemdを使用すると、カレンダーと単調なタイマーの構成に関して柔軟性が高まります。

実験中に作成したサービス構成ファイルは通常、タイマーを使用して呼び出されますが、などのコマンドを使用していつでも呼び出すことができますsystemctl start myMonitor.service。 1つのタイマーで複数のタスクを開始できます。これは、たとえば、BashスクリプトやLinuxユーティリティです。サービス構成ファイルは、呼び出されたときに複数のスクリプトが実行されるように構成できます。スクリプトを個別に実行することもできます。

systemd、cron、atの共存について話す場合、cronまたはatが非推奨になる兆候はまだ見られないことに注意してください。atは、少なくともsystemdよりも1回限りのタスクのスケジュールに使用する方がはるかに簡単なので、引き続きサポートされることを願っています。

何を使っていますか？Systemdタイマーまたはcronジョブ？

cronジョブの代わりにsystemdタイマーを使用する

システムメンテナンスに使用されるタイマー

タイマーの作成

タイマータイプ

カレンダーイベントの説明

,

追加資料

More articles: