cronjobsの代わりにsystemdタイマーを使用する

cronジョブをsystemdタイマーに変換中です。私は数年間タイマーを使用しましたが、通常、私は自分が取り組んでいるタスクを実行するのに十分なことを学びました。このsystemdシリーズの調査をしているときに、systemdタイマーには非常に興味深い機能があることを学びました。

cronジョブと同様に、systemdタイマーは、1日1回、特定の日（おそらく月曜日の場合のみ）、または営業時間中は15分ごとなど、指定された時間間隔でイベント（シェルスクリプトおよびプログラム）をトリガーできます。午前8時から午後6時まで。タイマーは、cronジョブでは実行できないいくつかのことも実行できます。たとえば、タイマーは、スクリプトまたはプログラムをトリガーして、起動、起動、前のタスクの完了、またはタイマーによって呼び出されたサービスユニットの前の完了などのイベントの後に特定の時間を実行できます。

> システムメンテナンスタイマー

Fedoraまたはsystemdベースのディストリビューションが新しいシステムにインストールされると、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つのタイマーには、ドキュメントへのポインターがあります。これは素晴らしい（ただしオプションの）データです。
最後の行は、タイマーによってトリガーされたサービスの最新のインスタンスのジャーナルエントリです。

ホストによっては、タイマーのセットが異なる可能性があります。

タイマーを作成する

1つまたは複数の既存のタイマーを分解してそれらがどのように機能するかを学習することはできますが、独自のサービスユニットとそれをトリガーするタイマーユニットを作成しましょう。これを単純にするために、かなり些細な例を使用します。これが完了すると、他のタイマーがどのように機能するかを理解し、それらが何をしているかを判断するのが簡単になります。

まず、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ジャーナルに送信され、現在または後で表示できるレコードが残ります。（このシリーズの今後の記事で、システム化されたジャーナリングと保持戦略について説明します。）サービスユニット専用のジャーナルと今日のみのジャーナルを見てください。 -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]#

サービスによってトリガーされるタスクは、単一のプログラム、一連のプログラム、または任意のスクリプト言語で記述されたスクリプトです。 [Service]の最後に次の行を追加して、サービスに別のタスクを追加します myMonitor.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.

サービスが期待どおりに機能することがわかったので、タイマーユニットファイルmyMonitor.timerを作成します。 /etc/systemd/systemにあります、および以下を追加します：

# 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 myMonitor.timer fileでの時間指定、*-*-* *:*:00 、myMonitor.serviceを実行するためにタイマーをトリガーする必要があります毎分単位。 OnCalendarを探索しますこの記事の後半で設定します。

今のところ、タイマーによってトリガーされたときのサービスの実行に関連するジャーナルエントリを確認してください。タイマーをフォローすることもできますが、サービスをフォローすると、ほぼリアルタイムで結果を確認できます。 journalctlを実行します -fを使用（フォロー）オプション：

[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.service

[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.

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

システム管理者の詳細

Sysadminブログを有効にする
自動化されたエンタープライズ：自動化によってITを管理するためのガイド
eBook：システム管理者向けのAnsible自動化
現場からの物語：IT自動化に関するシステム管理者ガイド
eBook：SREおよびシステム管理者向けのKubernetesのガイド
最新のシステム管理者の記事

あなたはおそらくジャーナルで少なくとも2つのことに気づいたでしょう。まず、STDOUTを発生させるために特別なことをする必要はありません。 ExecStartから myMonitor.serviceのトリガージャーナルに保存される単位。これはすべて、サービスを実行するためにsystemdを使用することの一部です。ただし、サービスユニットからのスクリプトの実行とSTDOUTの量に注意する必要がある場合があることを意味します。それらは生成します。

2つ目は、タイマーが正確にトリガーされないのは、00秒の分、または前のインスタンスから正確に1分であるということです。これは意図的なものですが、必要に応じて（または、システム管理者の感性を損なうだけの場合は）オーバーライドできます。

この動作の理由は、複数のサービスがまったく同時にトリガーされるのを防ぐためです。たとえば、Weekly、Dailyなどの時間指定を使用できます。これらのショートカットはすべて、トリガーされた日の00:00:00にトリガーされるように定義されています。このように複数のタイマーを指定すると、同時に起動しようとする可能性が高くなります。

systemdタイマーは、同時トリガーを防ぐために、指定された時間の前後にいくらかランダムにトリガーするように意図的に設計されています。これらは、指定されたトリガー時間で開始し、指定された時間に1分を加えた時間で終了する時間ウィンドウ内で半ランダムにトリガーします。 systemd.timerによると、このトリガー時間は、他のすべての定義済みタイマーユニットに対して安定した位置に維持されます。マニュアルページ。上記のジャーナルエントリを見ると、タイマーが開始するとすぐにトリガーされ、毎分約46秒または47秒後にトリガーされたことがわかります。

ほとんどの場合、このような確率的なトリガー時間は問題ありません。バックアップなどのタスクを実行するようにスケジュールする場合、それらが営業時間外に実行される限り、問題はありません。システム管理者は、他のタスクと競合しないように、一般的なcronジョブ仕様の01:05:00などの決定論的な開始時刻を選択できますが、それを実現する時間値にはさまざまなものがあります。通常、開始時間の1分間のランダム性は関係ありません。

ただし、一部のタスクでは、正確なトリガー時間が絶対要件です。その場合は、このようなステートメントをTimerに追加することで、トリガーのタイムスパンの精度を（マイクロ秒以内に）指定できます。タイマーユニットファイルのセクション：

AccuracySec=1us

タイムスパンを使用して、必要な精度を指定したり、繰り返しイベントまたは1回限りのイベントのタイムスパンを定義したりできます。次の単位を認識します：

usec、us、µs
ミリ秒、ミリ秒
秒、秒、秒、秒
分、分、分、m
時間、時間、時間、時間
日、日、日
週、週、w
月、月、M（30。44日として定義）
年、年、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にあるいくつかのタイマーユニットファイルの完全な内容を表示しますそれらがどのように構築されているかを確認するためのディレクトリ。

この実験でタイマーを有効にして起動時にアクティブにする必要はありませんが、有効にするコマンドは次のようになります。

# systemctl enable myMonitor.timer

作成したユニットファイルは実行可能である必要はありません。また、サービスユニットはタイマーによってトリガーされるため、有効にしませんでした。必要に応じて、コマンドラインから手動でサービスユニットをトリガーすることもできます。それを試して、ジャーナルを観察してください。

systemd.timerのマニュアルページを参照してくださいおよびsystemd.time タイマーの精度、イベント時間の仕様、トリガーイベントの詳細については、

タイマータイプ

systemdタイマーには、cronにはない他の機能があり、特定の反復的なリアルタイムの日付と時刻でのみトリガーされます。 systemdタイマーは、他のsystemdユニットのステータス変更に基づいてトリガーするように構成できます。たとえば、システムの起動後、起動後、または定義されたサービスユニットのアクティブ化後に、特定の経過時間をトリガーするようにタイマーを設定できます。これらは単調タイマーと呼ばれます。単調とは、継続的に増加するカウントまたはシーケンスを指します。これらのタイマーは、起動するたびにリセットされるため、永続的ではありません。

表1に、単調タイマーとそれぞれの簡単な定義、およびOnCalendarを示します。タイマー。単調ではなく、反復する場合としない場合がある将来の時間を指定するために使用されます。この情報は、systemd.timerから取得されます。いくつかの小さな変更を加えたmanページ。

タイマー単調定義

`OnActiveSec=`	X	これは、タイマーがアクティブ化された瞬間を基準にしたタイマーを定義します。
`OnBootSec=`	X	これは、マシンの起動時を基準にしたタイマーを定義します。
`OnStartupSec=`	X	これは、サービスマネージャが最初に起動したときを基準にしたタイマーを定義します。システムタイマーユニットの場合、これは`OnBootSec=`と非常によく似ています。、システムサービスマネージャは通常、起動時に非常に早い段階で起動するためです。ユーザーサービスマネージャーは通常、起動時ではなく、最初のログイン時にのみ起動するため、ユーザーごとのサービスマネージャーで実行されているユニットで構成されている場合に主に役立ちます。
`OnUnitActiveSec=`	X	これは、アクティブ化されるタイマーが最後にアクティブ化された日時を基準にしたタイマーを定義します。
`OnUnitInactiveSec=`	X	これは、アクティブ化されるタイマーが最後に非アクティブ化された日時を基準にしたタイマーを定義します。
`OnCalendar=`		これは、カレンダーイベント式を使用してリアルタイム（つまり、壁掛け時計）タイマーを定義します。 `systemd.time(7)`を参照してくださいカレンダーイベント式の構文の詳細については。それ以外の場合、セマンティクスは`OnActiveSec=`と同様です。および関連する設定。このタイマーは、cronサービスで使用されるタイマーに最もよく似ています。

表1：systemdタイマーの定義

単調タイマーは、AccuracySecと同じショートカット名を期間に使用できます。前述のステートメントですが、systemdはそれらの名前を秒に正規化します。たとえば、システムの起動から5日後に、イベントを1回トリガーするタイマーを指定できます。次のようになります：OnBootSec=5d 。ホストが2020-06-15 09:45:27で起動した場合、タイマーは2020-06-20 09:45:27にトリガーされますまたは1分以内。

カレンダーイベントの仕様

カレンダーイベントの仕様は、希望する繰り返し時間にタイマーをトリガーするための重要な部分です。 OnCalendarで使用されるいくつかの仕様を確認することから始めます設定。

systemdとそのタイマーは、crontabで使用される形式とは異なるスタイルの時刻と日付の指定を使用します。 crontabよりも柔軟性があり、atのようにあいまいな日付と時刻を許可します指図。また、理解しやすいように十分に精通している必要があります。

OnCalendar=を使用したsystemdタイマーの基本形式 DOW YYYY-MM-DD HH:MM:SSです。 DOW（曜日）はオプションであり、他のフィールドではアスタリスク（*）を使用してその位置の任意の値に一致させることができます。すべてのカレンダー時間フォームは、正規化されたフォームに変換されます。時刻が指定されていない場合は、00:00:00と見なされます。日付が指定されていないが時刻が指定されている場合、次の試合は現在の時刻に応じて今日または明日になる可能性があります。名前または番号は、月と曜日に使用できます。各ユニットのカンマ区切りリストを指定できます。単位範囲は..で指定できます開始値と終了値の間。

日付を指定するためのいくつかの興味深いオプションがあります。チルダ（〜）を使用して、月の最終日または月の最終日の前の指定された日数を指定できます。「/」を使用して、修飾子として曜日を指定できます。

OnCalendarで使用されるいくつかの典型的な時間仕様の例を次に示します。ステートメント。

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

DOW YYYY-MM-DD HH：MM：SS
--* 00:15:30	毎年毎月毎日深夜15分30秒後
毎週	毎週月曜日00:00:00
月--*00:00:00	毎週と同じ
月	毎週と同じ
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日、午前01時15分00秒
月*-05〜03	任意の年の5月の次の月曜日。これは月末から3日目でもあります。
Mon..Fri * -08〜04	平日にも該当する年の8月末の4日目。
*-05〜03/2	5月末から3日目、2日後。毎年繰り返します。この式はチルダ（〜）を使用していることに注意してください。
*-05-03/2	5月の3日目、それ以降は5月の残りの2日ごと。毎年繰り返します。この式はダッシュ（-）を使用していることに注意してください。

表2：サンプルのOnCalendar イベントの仕様

カレンダーの仕様をテストする

systemdは、タイマーのカレンダー時間イベント仕様を検証および検査するための優れたツールを提供します。 systemd-analyze calendar ツールは、カレンダーの時間イベントの仕様を解析し、正規化された形式と、次の「経過」の日時、つまり一致、トリガー時間に達するまでのおおよその時間など、その他の興味深い情報を提供します。

まず、時間のない将来の日付を確認します（Next elapseの時間に注意してくださいおよび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]#

To analyze the date and time as a single unit, enclose them together in quotes. Be sure to remove the quotes when using them in the OnCalendar= event specification in a timer unit or you will get errors:

[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]#

Now test the entries in Table 2. I like the last one, especially:

[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]#

Let’s look at one example in which we list the next five elapses for the timestamp expression.

[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 ~]#

This should give you enough information to start testing your OnCalendar time specifications. The systemd-analyze tool can be used for other interesting analyses, which I will begin to explore in the next article in this series.

Summary

systemd timers can be used to perform the same kinds of tasks as the cron tool but offer more flexibility in terms of the calendar and monotonic time specifications for triggering events.

Even though the service unit you created for this experiment is usually triggered by the timer, you can also use the systemctl start myMonitor.service command to trigger it at any time. Multiple maintenance tasks can be scripted in a single timer; these can be Bash scripts or Linux utility programs. You can run the service triggered by the timer to run all the scripts, or you can run individual scripts as needed.

I will explore systemd's use of time and time specifications in much more detail in the next article.

I have not yet seen any indication that cron and at will be deprecated. I hope that does not happen because at , at least, is much easier to use for one-off task scheduling than systemd timers.

Resources

There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.

The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
Linux.com's "More systemd fun" offers more advanced systemd information and tips.

There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.

Rethinking PID 1
systemd for Administrators, Part I
systemd for Administrators, Part II
systemd for Administrators, Part III
systemd for Administrators, Part IV
systemd for Administrators, Part V
systemd for Administrators, Part VI
systemd for Administrators, Part VII
systemd for Administrators, Part VIII
systemd for Administrators, Part IX
systemd for Administrators, Part X
systemd for Administrators, Part XI