朝から昼寝

ITや家計、身近なことの整理

[お知らせ]
当サイトは、2024年1月1日に
新URL(happynap.net)に引っ越しました





このページの内容は、最新ではない場合がありますので、新URLをご確認ください。






当サイトには広告を含みます。"オススメ"として紹介している商品やサービスは、個人的にそう思えたものだけです。
共感、興味をもっていただけるものがあればご利用ください (広告掲載ポリシー)。

Systemdによるサービス管理ノウハウ (基本)

概要

Systemdは、RHEL7、CentOS7以降における基本的なサービス管理機能 (等を含むシステム管理デーモンやツールの一式) です。従来はUpstart、SysVinitがありました。

本記事では、SystemdによるRHEL、CentOSのサービス管理に関する基本的なポイントをまとめます。

関連記事として、Systemdのネットワーク関連ユニットについて以下にまとめてあります。

happy-nap.hatenablog.com

本記事の目的

  • Systemdで管理されているサービスやその設定を確認する。
  • Systemdで管理されているサービスを手動で停止、起動する。
  • 自身で作成したプログラム等をSystemdのサービスとして登録する。

基本

Systemd の基本的なサービス管理コマンドについて説明します。

操作対象とするサービスは、httpd.serviceを例にします。

httpd.service は Apache HTTP Server のサービスが Systemd に登録されたものです。適宜、サービス名を読み替えてください。

サービス管理 (systemctl)

基本的なサービス管理コマンド、systemctl です。

各項目の詳細は$ man systemctlで確認できます。

サービスの起動状態の一覧表示(systemctl list-units)

現在のサービスの起動状態を一覧で確認する方法です。

$ systemctl list-units --all --type=service

UNIT          LOAD   ACTIVE SUB     DESCRIPTION
…
httpd.service loaded active running The Apache HTTP Server 
…
  • ACTIVE列にてサービス起動状態を確認可能
    • active : サービスが起動した状態である
    • inactive : サービスが停止した状態である
    • failed : サービスが何らかエラーの状態である(サービス起動失敗等)
    • (その他) reloading, activating, deactivating


  • SUB列でもサービス起動状態を確認可能(typeがサービスの場合)
    • running: プロセスが起動した状態である
    • exited: 処理を終えてプロセスが終了した状態である

--type serviceはサービスのみを表示するためのオプションです。省略するとサービス以外のUnitも表示されます。
特定のサービスのみ表示させる場合は、$ systemctl list-units httpd*のようにパターン指定するか、$ systemctl list-units | grep httpdのように実行します。

ACTIVE列とSUB列の違いは微妙ですが、プロセスが常時起動するサービスの場合、基本的にACTIVE列がactiveのときはSUB列はrunningになっているはずです。対して、処理の実行後、プロセスが終了する類の特殊なサービスはACTIVE列がactiveかつSUB列がexitedになります。

参考までに、コマンド実行時に以下の説明が表示されます。

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type. 

サービスの自動起動設定の一覧表示(systemctl list-unit-files)

サービスが自動起動する設定かどうかを確認する方法です。

$ systemctl list-unit-files --type service

UNIT FILE                                     STATE   
…
httpd.service                                enabled 
…
  • STATE列にてサービスの自動起動設定を確認可能
    • enabled : 自動起動が有効
    • disabled : 自動起動が無効
    • static : 単体では自動起動しない (staticはsystemctlで有効化、無効化できないもの。他サービスとの依存関係に従い起動するもの等)

サービスの起動/停止/再起動/リロード(systemctl start / stop / restart / reload)

サービスの起動や停止等の操作方法です。

(例としてhttpdサービスに対するコマンドを記載)

  • サービス起動
    # systemctl start httpd

  • サービス停止
    # systemctl stop httpd

  • サービス再起動
    # systemctl restart httpd

  • サービスリロード
    # systemctl reload httpd

reloadは、設定ファイルの変更点を反映する際に使用されます。

例えばhttpdであれば、httpd.confの変更点の反映などです。そのサービスの詳細仕様によりますが、reloadはrestartと異なり、基本的にサービス停止せず設定反映できます。ただし、サービスによってはreloadに対応していない場合があります(ユニットファイルにExecReloadが定義されていない場合)。

補足として、httpdの場合は reload により、内部的には httpd -k graceful が実行されるはずです。詳細はhttpdのマニュアルやユニットファイル (後述) を参照願います。

サービスの状態確認(systemctl status)

現在のサービスの起動状態を確認する方法です。

(例としてhttpdサービスに対するコマンドを記載)

$ systemctl status httpd  (★マークは説明用の目印です)

● httpd.service - The Apache HTTP Server
  Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled★; vendor preset: disabled)
  Active: active (running)★ since Thu 2022-05-01 02:02:02 UTC; 2min 2s ago
    Docs: man:httpd(8)
          man:apachectl(8)
Main PID: 5001 (httpd)
  Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
  CGroup: /system.slice/httpd.service
          ├─5002 /usr/sbin/httpd -DFOREGROUND
          ├─5003 /usr/sbin/httpd -DFOREGROUND
 …

Loaded:行は、Unitファイルのパスと、サービスの自動起動設定(enabled or disabled)が表示されます。前述のサービスの自動起動設定の一覧表示と同様の内容です。

Active:行は、サービスの起動状態(active or inactive等)が表示されます。前述のサービスの起動状態の一覧表示(systemctl list-units)と同様の内容です。

Main PID:行、CGroup:行は、それぞれメインプロセスと、メインプロセスからフォークされた子プロセスです。

詳細

もう少し詳しい内容です。

Unitの構成、種類

systemdはサービス等をUnitの単位で扱います。

ここでは、Unitの構成や配置について簡単に説明します。

ユニットファイル

Unitはファイル形式で定義されます。

そのファイル名の書式はunit_name.type_extensionです。

unit_nameは、そのユニットの名前(サービスであればサービス名)です。
type_extensionは、.service(サービスを定義するもの)、.target(複数のサービスをまとめるためのもの)、.device(デバイス)、.timer(cronのように使えるもの)等、他にもあります。
詳細は、man systemd.unitや、 RedHat社のマニュアルが参考になります。

ユニットファイルに関する主なパス

ユニットファイルの主な格納パスは以下です。

  • /usr/lib/systemd/system/:パッケージマネージャによって配置
  • /etc/systemd/system/:システム管理者によって配置

前者が、RPM等にデフォルトで含まれるユニットファイルが格納されるパスです。後者は、システム管理者が個別にユニットファイルを用意して格納するためのパスです。

同名のユニットファイルが /usr/lib/systemd/system//etc/systemd/system/ の両方に配置された場合、/etc/systemd/system 内のファイルが優先されます。

詳細は、 man systemd.unit の "UNIT FILE LOAD PATH" セクションや、開発元のドキュメントに記載があります。

例:httpdの場合

例えば、httpdの場合、関連するユニットファイルは以下です。

$ ls -l /usr/lib/systemd/system/

(★マークは説明用の目印です)
…
-rw-r--r--  1 root root  314  3月 22 02:27  httpd-init.service
-rw-r--r--  1 root root  944  3月 22 02:27  httpd.service ★
drwxr-xr-x  2 root root   26  4月 13 09:32  httpd.service.d
-rw-r--r--  1 root root  244  3月 22 02:27  httpd.socket
drwxr-xr-x  2 root root   31  4月 13 13:17  httpd.socket.d
-rw-r--r--  1 root root  662  3月 22 02:27  httpd@.service
…

ファイルがたくさんありますが、通常のWebサーバとして使用するhttpdサービスのユニットファイルはhttpd.serviceです。

ユニットを有効化した際の動作

# systemctl enable httpdによりユニットを有効化すると、そのユニットファイル内の定義 (後述の[Install]セクション) に従い動作します。

一般的なサービスであれば、/etc/systemd/system/multi-user.target.wants/配下にシンボリックリンクが作成されます。

このディレクトリ配下にあるユニットファイルは通常のマルチユーザモード(multi-user.target)でのシステム起動時に読み込まれますので、システム起動時にサービス自動起動することになります。

例として、httpd.serviceユニットファイル内の[Install]セクションは以下のように記載されています。

[Install]
WantedBy=multi-user.target

上記の記載により、このユニットを有効化すると、multi-user.target配下にシンボリックリンクが作成されるということです。

作成されたシンボリックリンクは以下です。
$ ls -l /etc/systemd/system/multi-user.target.wants/

…
lrwxrwxrwx  1 root root 37  4月 14 11:29 httpd.service -> /usr/lib/systemd/system/httpd.service
… 

ユニットファイルをカスタマイズする場合

サービス起動時のオプション変更等、ユニットファイルをカスタマイズしたい場合については、以下の記事にまとめてあります。

happy-nap.hatenablog.com

ユニットファイルの読み方

任意のプログラム等をSystemdのサービスとして登録にまとめて記載してあります。

(補足)テンプレート形式のユニット(name@xxx.service)

httpd@.serviceのように@(アットマーク)がついたサービスは、テンプレートです。例えば仮想コンソール(gettyやvnd等)で複数インスタンス起動するようなサービスの場合に使用されます。
systemctl start name@1.servicesystemctl enable name@1.serviceのように、@の後に任意の文字列を指定できます。(getty@tty1.service等)
@の後に指定した文字列は、ユニットファイル内の%l %i 変数に置き換えられます。

任意のプログラム等をSystemdのサービスとして登録

以下の流れです。

  1. サービスとして実行するプログラムを準備
  2. ユニットファイルを作成
  3. 作成したユニットファイルを読み込み、有効化

1. サービスとして実行するプログラムを準備

任意のプログラムを準備します。
プログラムの例として、簡単なシェルスクリプトを作成します。
# vi /usr/local/bin/sleeping.sh

#!/bin/sh
while true; do echo "zzz..." >> /tmp/sleeping.log; sleep 5 ; done

2. ユニットファイルを作成

/etc/systemd/system/配下にユニットファイルを作成します。各オプションの詳細はman systemd.serviceman systemd.unitで確認できます。
# vi /etc/systemd/system/sleeping.service

[Unit]
Description = just keep sleeping process

[Service]
ExecStart = /usr/local/bin/sleeping.sh
Type = simple

[Install]
WantedBy = multi-user.target

上記はとてもシンプルなユニットファイルの例です。実際の運用に際しては、マニュアルを参照の上、各オプションの精査が必要です。

  • [Unit]セクションのオプション ([Unit]セクションは任意)

    • Description:ユニットの説明
    • After:このAfterオプションで指定したユニットの起動開始後に自身のユニットを起動開始する。
    • Before:Afterの逆。
    • Wants:自身のユニットの起動時に、このWantsオプションで指定したユニットを起動する。緩い依存関係を指定しており、指定したユニットの起動が失敗しても自身のユニットは起動しようとする。
    • Requires:Wantsと同様に依存関係を指定するが、必須の依存関係を指定しており、指定したユニットの起動が失敗した場合に自身のユニットは起動失敗として扱われる。

    After、Beforeはサービス起動の「順序関係」を指定するオプションです。Wants、Requiresは「依存関係」を指定するオプションです。なお、Wants、Requiresを指定しても、起動の「順序」は制御されません。

  • [Service]セクションのオプション ([Service]セクションは必須)
    [Service]セクションは、サービス定義において重要です。いくつか記載しますが、他にも多くのオプションがあります。

    • ExecStart:サービス起動時(systemctl start)に実行するコマンド。
    • ExecStop:サービス停止時(systemctl stop)に実行するコマンド。
    • ExecReload:サービスリロード時(systemctl reload)に実行するコマンド。
    • Restart:サービスのプロセス停止時の挙動を指定。デフォルトはno(再起動しない)。例えばalwaysに指定するとプロセスが終了時には再起動される。
    • Type:サービスの起動方法。この指定に従いサービスが正常起動したかを判定する。例えば、プログラム単体を実行し続けるものであればsimpleを指定、子プロセスがそのサービスのメインプロセスになるものであればforkingを指定する。より詳細にサービスの起動判定を行いたい場合はnotify(やdbus)の指定が推奨される。
      • simple:ExecStartで指定したコマンドがサービスのメインプロセスである場合に使用する。プロセス生成した時点でサービス起動完了と判定する。ただし、プロセス生成後にExecStartで指定したコマンドを正常に実行できなくてもサービス起動が成功した扱いとなる(例:Userオプションで指定したユーザが存在しない場合でもサービス起動成功となる、等)。
      • forking:ExecStartで指定したコマンドにより実行されたプロセス(親)から起動(フォーク)された子プロセスがサービスとして動作する場合に使用する。親プロセスが終了した時点で起動完了と判定する。PIDFileオプションの使用が推奨される。なお、man systemd.serviceには、近年PIDFileが使用されないため、特に必要性が無ければType=notifyかType=simpleを使用するよう記載がある。
      • notify:simpleと同様、ExecStartで指定したコマンドがサービスのメインプロセスである場合に使用するが、そのプロセスがsystemdのライブラリ関数sd_notify()に対応している場合に使用する。プロセスは自身の起動完了をsd_notify()にてsystemdに通知する。
      • oneshot:simpleと同様、ExecStartで指定したコマンドがサービスのメインプロセスである場合に使用するが、そのプロセスが終了した時点で起動完了と判定する。その後、(RemainAfterExit=yesを指定しない限り)activeになることはなく、そのままサービスは停止(deactivatingやdead)となる。なお、RemainAfterExit=yesを指定した場合、コマンド終了後もサービスはactiveな状態となる。
    • PIDFile:PIDファイルのパスを指定する。主に、Type=forkingのサービスではこのオプションでメインプロセスのPIDファイルを指定することが推奨される。
       
  • [Install]セクションのオプション ([Install]セクションは任意)
    • WantedBy:このWantedByオプションで指定したユニットの起動時、自身のユニットを起動する。

    [Install]セクションでは、systemctl enablesystemctl disableでユニットを有効化、無効化した際の処理を定義します。例えば、enable時にはWantedByで指定したユニットの.wantsディレクトリに自身のユニットを登録する等です。 前述のWantsの逆でWantedBy、Requiresの逆でRequiredByというオプションがあります。これらは、そのオプションで指定したユニットの起動時に自身のユニットを起動するものです。

3. 作成したユニットファイルを読み込み、有効化

ユニットファイルを作成後、以下のように反映、有効化することでシステム起動時に自動起動するサービスとして設定完了です。

ユニットファイルの変更後は以下のようにsystemdにて読み込みが必要です。
# systemctl daemon-reload

作成したユニットファイルのサービスを有効化します。
# systemctl enable sleeping

手動でサービスを起動する際には以下のコマンドを実行します。
# systemctl start sleeping

上記のシェルスクリプトは、ファイル/tmp/sleeping.logに文字列を出力するものなので、ファイルの中身を確認すると、その動作を確認できます。
# tail -f /tmp/sleeping.log

参考

サービス起動時のエラー等

systemctlコマンドによるサービス起動が失敗した際には以下のようなメッセージが表示されます。
# systemctl start httpd

(サービス起動失敗時のメッセージ例)
Job for httpd.service failed because the control process exited with error code.
See "systemctl status httpd.service" and "journalctl -xe" for details. 

メッセージの指示に従い、# systemctl status httpd.service and journalctl -xeにてログを確認することが可能です。あるいは、messagesにもログが出力されている場合があります。

ユニットファイルの例

備忘用に、httpdデフォルトのユニットファイルを記載しておきます(RHEL8系)。

httpd.service (httpd本体)

/usr/lib/systemd/system/httpd.service

# See httpd.service(8) for more information on using the httpd service.

# Modifying this file in-place is not recommended, because changes
# will be overwritten during package upgrades.  To customize the
# behaviour, run "systemctl edit httpd" to create an override unit.

# For example, to pass additional options (such as -D definitions) to
# the httpd binary at startup, create an override unit (as is done by
# systemctl edit) and enter the following:

#       [Service]
#       Environment=OPTIONS=-DMY_DEFINE

[Unit]
Description=The Apache HTTP Server
Wants=httpd-init.service
After=network.target remote-fs.target nss-lookup.target httpd-init.service
Documentation=man:httpd.service(8)

[Service]
Type=notify
Environment=LANG=C

ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
# Send SIGWINCH for graceful stop
KillSignal=SIGWINCH
KillMode=mixed
PrivateTmp=true

[Install]
WantedBy=multi-user.target

httpd-init.service (TLS用の鍵生成をするためのoneshotのサービス)

/usr/lib/systemd/system/httpd-init.service

[Unit]
Description=One-time temporary TLS key generation for httpd.service
Documentation=man:httpd-init.service(8)

ConditionPathExists=|!/etc/pki/tls/certs/localhost.crt
ConditionPathExists=|!/etc/pki/tls/private/localhost.key

[Service]
Type=oneshot
RemainAfterExit=no

ExecStart=/usr/libexec/httpd-ssl-gencerts

httpd\@.service (テンプレート)

/usr/lib/systemd/system/httpd\@.service

# This is a template for httpd instances.
# See httpd@.service(8) for more information.

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd@.service(8)

[Service]
Type=notify
Environment=LANG=C
Environment=HTTPD_INSTANCE=%i
ExecStartPre=/bin/mkdir -m 710 -p /run/httpd/instance-%i
ExecStartPre=/bin/chown root.apache /run/httpd/instance-%i
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND -f conf/%i.conf
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful -f conf/%i.conf
# Send SIGWINCH for graceful stop
KillSignal=SIGWINCH
KillMode=mixed
PrivateTmp=true

[Install]
WantedBy=multi-user.target

まとめ

本記事では、SystemdによるRHEL、CentOSのサービス管理に関する基本的なポイントをまとめてみました。

参考

開発プロジェクト (アップストリーム)

RHELのマニュアル

関連記事

happy-nap.hatenablog.com

happy-nap.hatenablog.com

happy-nap.hatenablog.com

happy-nap.hatenablog.com

chronyによる時刻同期ノウハウ1(基本的な設定)

概要

chronyは、RHEL7、CentOS7以降におけるデフォルトの時刻同期機能(NTP実装)です。従来はntpdがありました。

本記事は、常時起動させておくサーバにおいてchronyをNTPクライアントとして使用する方法をまとめたものです。主に、RHEL7、CentOS7以降でOS標準のchronyを使用した環境を対象としていますが、基本的にはどのシステムでも共通です。
2023年10月更新: RHEL7系 (chrony-3.4 ベース) を対象に記載していましたが、RHEL9系 (chrony-4.3 ベース) との差分を確認し、気付いた点は補足しました。

本記事は基本的な内容を説明したものです。

もう少し応用的な内容として、NTPサーバの複数指定や移行についての記事は以下です。

happy-nap.hatenablog.com

Stable Diffusionで作成 (プロンプト:time synchronization effect, cyber space background, dark terminal prompt)
Stable Diffusionで作成 (プロンプト:time synchronization effect, cyber space background, dark terminal prompt)

本記事の目的
  • chronyでNTPサーバを参照して時刻同期する。
  • 時刻ズレやうるう秒の発生時に考慮すべきポイントを抑えておく。

基本

参照先NTPサーバの指定(server)

設定ファイルを編集します。
# vi /etc/chrony.conf

#server 0.rhel.pool.ntp.org   iburst 
#server 1.rhel.pool.ntp.org   iburst 
#server 2.rhel.pool.ntp.org   iburst 
#server 3.rhel.pool.ntp.org   iburst
server ntp-server1.domain.com iburst
server ntp-server2.domain.com iburst

serverディレクティブは使用するNTPサーバを指定します。上記の1~4行目は、RHEL用のデフォルト設定です。別のNTPサーバを使用する場合には、全てコメントアウトします。
新たにserver行を追加し、ntp-serverX.domain.com部分に参照先NTPサーバを記載します。

iburstオプションは、chronyd起動時、NTPサーバに対し短い間隔で4回問合せし、早く時刻同期できるようにするものです。特に理由が無ければiburstを記載したままで良いです。
※補足: Chronyのたぶん4系から少し動作が変わり、NTPサーバ (ソース) がofflineからonlineに変わったときにも同様の動作となり、回数も4でなく4-8となったようです (chrony 4.0リリースノートGitLab)。

参照するNTPサーバが複数ある場合、複数行に分けて記載します。

もう少し詳しい内容や、serverpoolの違い等については、別記事にまとめてあります。

設定反映

/etc/chrony.confの変更後はサービスを再起動して設定反映します。
# systemctl restart chronyd
# systemctl status chronyd

…
Active: active (running) since xxx
…

Active:行が「active (running)」、since xxxが# systemctl restartを実行した時刻になっていればサービス再起動完了です。

動作確認

NTPサーバと時刻同期できていることの確認(chronyc sources)

$ chronyc sources

MS Name/IP address         Stratum Poll Reach LastRx Last sample               
========================================================
^* ntp-server1.domain.com          1   3   111    22  -1000us[ -100ms] +/-   10ms
^? ntp-server2.domain.com          1   3   111    22  -1000us[ -100ms] +/-   10ms
※値はダミーです

行頭が ^* になっている行のNTPサーバと時刻同期できています (best source)。

行頭が ^? になっている行のNTPサーバとは、通信が成功していません。通信に問題がある場合、NTPサーバの状況確認や、ファイアウォールの設定確認等の対処が必要です。※補足: chrony 4系のmanでは"not selectable"的な記載も増えており、通信不可も含めて何らかの理由で時刻ソースとして選択できない状態を示すことが説明されています(GitLab)

通信可能なNTPサーバであっても、chronydのサービス起動後、数秒~数十秒(長くて数分程度)は^? のままで、その後 ^* になります。
各項目の簡易説明は$ chronyc -v sourcesで表示できます。詳細は$ man chronycで確認できます。
他に$ chronyc trackingというオプションもあるので、それは後述します。

詳細

stepモードによる時刻同期の考慮(makestep)

chronyd のデフォルト設定では、サービス起動時にシステムクロックの時刻がNTPサーバと大幅にズレていた場合、一気に時刻修正(stepモード)が行われます。
デフォルトではchrony.confの「makestep 1.0 3」という設定により、chronyd起動直後のNTPサーバとのやり取り時に1.0 秒以上の時刻ズレが3回続けて検知された場合にstepモードで時刻修正されます。
一気に時刻修正されると問題があるシステムでは、この設定を予め無効化するか、より詳細に時刻関連の設定をチューニングしましょう。例えば、時刻を正確に扱う必要性のあるデータベースシステムなどです。
無効化する場合は、chrony.confのmakestep行をコメントアウトしてchronydを再起動します。
# vi /etc/chrony.conf

#makestep 1.0 3

なお、このmakestepによる動作は、chronydのサービス起動時に適用されます。つまり、OS再起動時だけでなく、chronydのサービスを再起動しただけでも適用されます。
makestepによる動作を無効化した環境では、サービス起動時にシステムクロックの時刻がNTPサーバと大幅にズレるような状況が生じないよう注意が必要です(サスペンドからの復帰時等)。ズレが大きすぎると、NTPサーバとうまく同期できなかったり、時刻修正の完了までに時間がかかる可能性があります。

うるう秒発生時の振る舞いの考慮(leapsecmode)

数年に1度、うるう秒により60秒目が挿入されることがあります。23:59:60(日本時刻で8:59:60)。システムによっては問題が生じる可能性があるため、うるう秒発生時の振る舞いを考慮しておく必要性があります。

2035年までにうるう秒が廃止される件については、別記事にまとめてあります。

chronyをNTPクライアントとして使用する場合

leapsecmodeディレクティブにより、うるう秒発生時の動作を指定します。

leapsecmodeのデフォルトは"system"です。これはシステムクロックが23:59:59を2回刻むことになるので、1秒間の時刻の逆進が発生します。なお、OSがうるう秒をサポートしていない場合のデフォルト値は"step"です。"step"の場合も、うるう秒発生時の動作は"system"と同様ですが、カーネルでなくchronyがシステムクロックを修正します。

うるう秒発生時の1秒間の逆進を回避したい場合、"slew"の設定が可能です。

  • leapsecmode slew
    うるう秒発生時、システムクロックを徐々に修正します。うるう秒により生じる1秒の時刻差を、デフォルトでは12秒間で修正します(後述のmaxslewrate)。

その他、"ignore"の設定がありますが、"slew"で十分と思われます。

  • leapsecmode ignore
    うるう秒発生時、システムクロックに何も修正を加えません。chronydの通常動作として、その後徐々にシステムクロックを修正します。$ man chrony.confでは、このオプションは複数のchronydが動作する環境において有用であると記載されています(1つはシステムクロックを修正するもの、他はNTPサーバ等の用途(-x)で動作するもの)。

(参考)chronyをNTPサーバとして使用する場合

chronyをNTPサーバとして使用し、他のNTPクライアントから参照させる場合に、うるう秒発生時の時刻修正を緩やかにするための設定例です。
$ man chrony.confでは、うるう秒対策(leap smear)として、以下の設定例が記載されています。

leapsecmode slew
maxslewrate 1000
smoothtime 400 0.001 leaponly

この設定は、うるう秒挿入時に23:59:59を2回刻まずシステムクロックをゆっくり時刻調整(slewモード)します。また調整速度(maxslewrate)を1000ppmに抑えます(maxslewrateについては後述)。smoothtimeは正確に理解できていませんが、システムが長時間オフラインだった場合などに備え、時刻修正速度の変化を緩やかにするためのオプションのようです。うるう秒発生時にのみ適用されます(leaponly)。
このうるう秒対策の設定は一部の古いシステムでは対応不可のようですので、使用しているシステムのchronyのマニュアル等を確認しましょう。
なお、上記のmaxslewrate 1000は、デフォルトの約80分の1の値です。うるう秒挿入時だけでなく普段の時刻修正の最大速度が制限される設定であるという点は認識しておくべきです(maxslewrateについては後述)。
このうるう秒対策の日本語解説は、RedHat社のページにあります。

時刻修正の速さ(maxslewrate)

chronydは通常動作時、slewモードでゆっくり時刻修正されます。その時刻修正の最大速度がmaxslewrateで設定されます。
maxslewrateのデフォルト値は83333.333 ppmで、これは「1秒の時刻ズレを12秒間で修正」するものです。単位がppm(parts per million)なので、83,333.333 ÷ 1,000,000 ≒ 0.083 (1秒間に1/12秒くらい時刻修正する)ということです。1分間の時刻ズレを修正するのにかかる時間が最速で720秒(12分)です。
従来のntpdでは、500ppm相当の固定値でしたので、それに比べるとかなり速いです。
大きな時刻ズレが生じたときに、条件によってはずっと時刻修正が完了しないままになるといったようなトラブルを回避する上ではある程度速い方が良いです。

動作確認

NTPサーバとの時刻同期状況の詳細確認(chronyc tracking)

前述のchronyc sources以外に、以下のような確認も可能です。
$ chronyc tracking

(★マークは説明用の目印です)
Reference ID    : AB00123C (domain.com)
Stratum         : 1
Ref time (UTC)  : Fri Apr 29 01:22:33 2022
System time     :  0.000000555 seconds slow of NTP time ★
Last offset : -0.000000140 seconds ★ 
RMS offset : 0.000000280 seconds ★
Frequency       : 1.111 ppm slow
Residual freq   : 0.000 ppm
Skew            : 0.090 ppm
Root delay      : 0.00140302 seconds
Root dispersion : 0.001200221 seconds
Update interval : 54.1 seconds
Leap status     : Normal
※値はダミーです。

System Time:行は「X seconds slow of NTP time」と記載されていれば、NTPサーバより時刻がX秒遅れている、「X seconds fast of NTP time」と記載されていれば、NTPサーバより時刻がX秒進んでいるという意味です。
offsetは、算出されたシステムクロックとNTPサーバとの間の時刻差です。Last offsetは、前回の計測時のoffsetであり、正の値はシステムクロックがNTPサーバよりも時刻が進んでいることを示します。RMS offsetは、長期間の平均のoffsetです。

まとめ

本記事では、常時起動させておくサーバにおいてchronyをNTPクライアントとして使用する方法をまとめてみました。

もう少し応用的な内容は、以下の記事にまとめてあります。
happy-nap.hatenablog.com

参考

他にもchronycにはオプションがあります。詳細は$ man chronycにて。

chrony.confの各設定詳細は$ man chrony.confにて。

RHEL9のマニュアル

開発プロジェクト (アップストリーム)

chronyの開発プロジェクトは、chrony – Introductionです。

Red Hat (Fedora) 側で改修されている点もある気はしますが、chrony自体の仕様や動作を詳しく理解されたい場合には、こちらのドキュメントを見た方が良いかと思います。

関連記事

happy-nap.hatenablog.com

happy-nap.hatenablog.com

happy-nap.hatenablog.com

happy-nap.hatenablog.com

テンプレート用記事

概要

新たに記事を作成する際、テンプレートを用意しておくと便利です。
本記事は、当サイトのテンプレート用記事です。

当サイトのトップページはこちらです。

末尾に本記事のもとになっているMarkdownのソースを記載します。

本記事の目的

  • テンプレートを用意しておく。

基本

見出し(h3)

詳細

インラインコード、コードブロック

command にて…。

コードブロック
コードブロック(シンタックスハイライト)

No. 項目名 説明
1 a b
2 c d
3 e f

引用

blank指定リンク



引用元

citeリンク



https://happy-nap.hatenablog.com/

画像

画像
画像

※引用時
引用元

箇条書き

  • a
  • a
  • a

(Markdownでは数字の箇条書きは使用しないことにする)

箇条書き(詳細)

…。

  • 1
    …。

    • 1-1
    • 1-2
      …。

    …。

  • 2
    …。

    • 2-1
    • 2-2
      …。

    …。

…。

まとめ

本記事では…。

参考情報、関連記事等

h1(記事内では使用しない)

h2

h3

h4

h5
h5

本記事のMarkdown

## 概要
新たに記事を作成する際、テンプレートを用意しておくと便利です。  
本記事は、当サイトのテンプレート用記事です。  

当サイトの<a href="https://happy-nap.hatenablog.com/" target="_blank" rel="nofollow noopener">トップページはこちら</a>です。  

末尾に本記事のもとになっているMarkdownのソースを記載します。   

**本記事の目的**

- テンプレートを用意しておく。  

[:contents]

## 基本
### 見出し(h3)

…

## 詳細
### インラインコード、コードブロック  

`command`にて…。

```
コードブロック
```

```c
コードブロック(シンタックスハイライト)
```

### 表  

|No.|項目名|説明|
|---|---|---|
|1|a|b|
|2|c|d|
|3|e|f|

### 引用  

blank指定リンク  
> …  
> …  
<a href="https://happy-nap.hatenablog.com/" target="_blank" rel="nofollow noopener">引用元</a>  

citeリンク  
> …  
> …  
> <cite>[https://happy-nap.hatenablog.com/]</cite>  

### 画像  

<figure class="figure-image figure-image-fotolife" title="画像">[f:id:happy-nap:20221225102448p:plain:alt=画像:w300]<figcaption>画像</figcaption></figure>

※引用時  
<cite><a href="https://happy-nap.hatenablog.com/" target="_blank" rel="nofollow noopener">引用元</a></cite>

### 箇条書き  

- a  
- a  
- a  

(Markdownでは数字の箇条書きは使用しないことにする)

#### 箇条書き(詳細)  

…。

- 1  
  …。
  - 1-1  
  - 1-2  
    …。

  …。  

- 2  
  …。
  - 2-1  
  - 2-2  
    …。  

  …。  

…。  


## まとめ  

本記事では…。

##  参考情報、関連記事等

- <a href="https://happy-nap.hatenablog.com/" target="_blank" rel="nofollow noopener" rel="nofollow noopener">リンク先</a>

- 本記事は、<a href="https://icons8.com/" target="_blank" rel="nofollow noopener">Icons8</a>のアイコンを使用しています(Icons by <a href="https://icons8.com/" target="_blank" rel="nofollow noopener">Icons8</a>)。

# h1(記事内では使用しない)
## h2
### h3
#### h4
##### h5
###### h5

お問い合わせ

  • ご返信に日数を要する場合があります。
  • 当サイトにてご返信の必要がないと判断した場合、ご返信を控えさせていただきます。
  • 送信いただく情報の取り扱いについては、プライバシーポリシー等を参照願います。