Linux の時刻同期: NTP、Chrony、systemd-timesyncd

ほとんどの人は時間を記録しています。 私たちは時間通りに起きて朝の儀式を終えて仕事に行き、昼休みを取り、プロジェクトの締め切りを守り、誕生日や祝日を祝い、飛行機に乗ります。

さらに、私たちの中には時間に執着している人もいます。 私の時計は太陽エネルギーで動作しており、国立標準技術研究所から正確な時刻を取得しています (NIST) 長波無線でコロラド州フォートコリンズへ WWVB。 時報は同じくフォートコリンズにある原子時計と同期しています。 Fitbit はサーバーと同期している携帯電話と同期しています NTP、最終的には原子時計と同期します。

デバイスも時間を追跡します

私たちのデバイスやコンピューターが正確な時刻を必要とする理由はたくさんあります。 たとえば、銀行、株式市場、その他の金融ビジネスでは、トランザクションは適切な順序で実行される必要があり、そのためには正確な時間順序が重要です。

携帯電話、タブレット、自動車、GPS システム、コンピューターはすべて、正確な時刻と日付の設定が必要です。 コンピュータのデスクトップ上の時計が正しい時刻を表示するようにしたいです。 ローカルカレンダーに適切なタイミングでリマインダーが表示されるようにしたいです。 時刻が正しいと、cron ジョブと systemd ジョブが正しい時刻に実行されることも保証されます。

ログには日付と時刻も重要であるため、日付と時刻に基づいて特定のログを見つけるのが少し簡単になります。 たとえば、私はかつて DevOps (当時はそう呼ばれていませんでした) で働いており、ノースカロライナ州で電子メール システムをセットアップしていました。 以前は 20 日に XNUMX 万件以上のメールを処理していました。 それぞれのコンピュータが同期されていれば、一連のサーバーを介して電子メールを追跡したり、地理的に分散したホスト上のログ ファイルを使用してイベントの正確な順序を特定したりすることがはるかに簡単になります。

XNUMX 回から何時間も

Linux ホストでは、システム時間と RTC 時間が存在することを考慮する必要があります。 RTC (Real Time Clock) は、ハードウェア クロックの少し奇妙で、あまり正確ではない名前です。

ハードウェア クロックは、コンピュータの電源がオフの場合でも、システム マザーボードのバッテリを使用して継続的に動作します。 RTC の主な機能は、タイム サーバーへの接続が利用できない場合に時刻を保存することです。 インターネット経由でタイム サーバーに接続することが不可能だった時代、すべてのコンピュータには正確な内部時計が必要でした。 オペレーティング システムは起動時に RTC にアクセスする必要があり、ユーザーは BIOS ハードウェア構成インターフェイスを使用してシステム時刻を手動で設定し、それが正しいことを確認する必要がありました。

ハードウェア クロックはタイム ゾーンの概念を理解していません。 RTC は時刻のみを保存し、タイム ゾーンや UTC (協定世界時、GMT またはグリニッジ標準時とも呼ばれます) からのオフセットは保存しません。 RTC は、この記事で後ほど説明するツールを使用してインストールできます。

システム時刻は、OS がデスクトップ上の GUI クロック、date コマンドの出力、ログのタイムスタンプに表示する時刻です。 これは、ファイルが作成、変更、および開かれたときにも当てはまります。

ページ上 RTCの人 RTC とシステム クロックの詳細な説明があります。

NTP とは何ですか?

世界中のコンピュータは、NTP (Network Time Protocol) を使用して、NTP サーバーの階層を使用してインターネット上の標準基準クロックと時刻を同期させます。 主要なタイム サーバーはレイヤー 1 にあり、衛星、無線、さらには電話回線上のモデムを介してレイヤー 0 のさまざまな国家時刻サービスに直接接続されています。 レイヤ 0 時刻サービスには、原子時計、原子時計によって送信される信号に同調される無線受信機、または GPS 衛星によって送信される高精度のクロック信号を使用する GPS 受信機などがあります。

リファレンス サーバーの大部分には、数千台のパブリック NTP Stratum 2 サーバーが公開されています。 NTP サーバーを必要とする多数のホストを持つ多くの組織やユーザー (私自身を含む) は、独自のタイム サーバーを設定して、2 つのローカル ホストだけがストラタム 3 または 3 にアクセスすることを選択します。その後、ネットワーク上の残りのノードがローカル サーバーを使用するように構成します。タイムサーバー。 私のホーム ネットワークの場合、これはレイヤー XNUMX サーバーです。

NTP のさまざまな実装

NTP の元の実装は ntpd です。 その後、chronyd と systemd-timesyncd という XNUMX つの新しいものが加わりました。 XNUMX つとも、ローカル ホストの時刻を NTP タイム サーバーと同期します。 systemd-timesyncd サービスは chronyd ほど信頼性がありませんが、ほとんどの目的には十分です。 RTC が同期していない場合、ローカル システム時刻がわずかにずれると、NTP サーバーと同期するようにシステム時刻を徐々に調整できます。 systemd-timesync サービスはタイム サーバーとして使用できません。

クロニー これは、chronyd デーモンと chronyc と呼ばれるコマンド ライン インターフェイスの XNUMX つのプログラムを含む NTP の実装です。 Chrony には、多くの場合に不可欠な機能がいくつかあります。

• Chrony は、古い ntpd サービスよりもはるかに高速にタイム サーバーと同期できます。 これは、常に動作しないラップトップまたはデスクトップに適しています。
• ホストがスリープするときやスリープ モードに入るとき、または低負荷時にクロックが遅くなる周波数ホッピングによってクロックが変化するときなど、クロックの変動を補正できます。
• 不安定なネットワーク接続やネットワークの混雑に関連する時間の問題を解決します。
• ネットワーク遅延を調整します。
• 最初の時刻同期の後、Chrony は時計を停止しません。 これにより、多くのシステム サービスとアプリケーションに安定した一貫したタイムスロットが提供されます。
• Chrony はネットワークに接続していなくても動作します。 この場合、ローカル ホストまたはサーバーを手動で更新できます。
• Chrony は NTP サーバーとして機能できます。

繰り返しになりますが、NTP は、Chrony または systemd-timesyncd を使用して Linux ホストに実装できるプロトコルです。

NTP、Chrony、systemd-timesyncd RPM は、標準の Fedora リポジトリで利用できます。 systemd-udev RPM は、Fedora にデフォルトでインストールされるカーネル イベント マネージャーですが、オプションです。

XNUMX つすべてをインストールしてそれらを切り替えることもできますが、これによりさらに頭の痛い問題が発生します。 だから、しないほうがいいのです。 Fedora、CentOS、RHEL の最新リリースはデフォルト実装として Chrony に移行しており、systemd-timesyncd も備えています。 Chrony はうまく機能し、NTP サービスよりも優れたインターフェイスを提供し、はるかに多くの情報と制御を提供するため、システム管理者は確実に満足できると思います。

NTPサービスの無効化

NTP サービスはホスト上ですでに実行されている可能性があります。 その場合は、他のものに切り替える前に無効にする必要があります。 chronyd を実行していたので、次のコマンドを使用して停止し、無効にしました。 ホスト上で実行している NTP デーモンに対して適切なコマンドを実行します。

[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#

サービスが停止され、無効になっていることを確認します。

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP client/server
     Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:chronyd(8)
             man:chrony.conf(5)
[root@testvm1 ~]#

打ち上げ前のステータスチェック

システム クロックの同期ステータスにより、NTP サービスが実行されているかどうかを判断できます。 まだ NTP を開始していないため、timesync-status コマンドはこれを示唆します。

[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.

ステータスを直接リクエストすると、重要な情報が得られます。 たとえば、引数やオプションを指定しない timedatectl コマンドは、デフォルトで status サブコマンドを実行します。

[root@testvm1 ~]# timedatectl status
           Local time: Fri 2020-05-15 08:43:10 EDT  
           Universal time: Fri 2020-05-15 12:43:10 UTC  
                 RTC time: Fri 2020-05-15 08:43:08      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: no                          
              NTP service: inactive                    
          RTC in local TZ: yes                    

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#

これにより、ホストの現地時間、UTC 時間、および RTC 時間が得られます。 この場合、システム時刻は America/New_York (TZ) タイム ゾーンに設定され、RTC はローカル タイム ゾーンの時刻に設定され、NTP サービスはアクティブではありません。 RTC 時刻がシステム時刻からわずかにずれ始めています。 これは、クロックが同期されていないシステムでは正常です。 ホスト上のオフセット量は、システムが最後に同期されてからの経過時間によって異なります。

また、RTC に現地時間を使用することに関する警告も受け取りました。これは、タイム ゾーンの変更と DST 設定に適用されます。 変更を加える必要があるときにコンピュータの電源がオフになっている場合、RTC は変更されません。 しかし、サーバーやその他のホストが XNUMX 時間稼働している場合、これはまったく問題になりません。 さらに、NTP 時刻同期を提供するサービスは、最初の起動段階でホストの時刻を調整するため、起動完了後に時刻が再び正確になります。

タイムゾーンの設定

通常、タイム ゾーンはインストール手順中に指定し、後で変更する必要はありません。 ただし、タイムゾーンを変更する必要がある場合があります。 役立つツールがいくつかあります。 Linux は、タイムゾーン ファイルを使用してホストのローカル タイムゾーンを決定します。 これらのファイルはディレクトリにあります /usr/share/zoneinfo。 私のタイムゾーンでは、デフォルトでシステムが次のように規定しています。 /etc/localtime -> ../usr/share/zoneinfo/America/New_York。 ただし、タイムゾーンを変更するためにそのような微妙な点を知る必要はありません。

重要なことは、自分の場所の正式なタイムゾーン名と、対応するコマンドを知ることです。 タイムゾーンをロサンゼルスに変更したいとします。

[root@testvm2 ~]# timedatectl list-timezones | column
<SNIP>
America/La_Paz                  Europe/Budapest
America/Lima                    Europe/Chisinau
America/Los_Angeles             Europe/Copenhagen
America/Maceio                  Europe/Dublin
America/Managua                 Europe/Gibraltar
America/Manaus                  Europe/Helsinki
<SNIP>

これでタイムゾーンを設定できるようになりました。 変更を確認するために date コマンドを使用しましたが、timedatectl を使用することもできます。

[root@testvm2 ~]# date
Tue 19 May 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Tue 19 May 2020 01:48:23 PM PDT
[root@testvm2 ~]#

これで、ホストのタイムゾーンを現地時間に戻すことができます。

systemd-timesyncd

systemd timesync デーモンは、systemd コンテキストで管理しやすい NTP 実装を提供します。 Fedora と Ubuntu にはデフォルトでインストールされます。 ただし、デフォルトでは Ubuntu でのみ起動します。 他のディストリビューションについてはわかりません。 自分で確認できます。

[root@testvm1 ~]# systemctl status systemd-timesyncd

systemd-timesyncd の構成

systemd-timesyncd の設定ファイルは次のとおりです。 /etc/systemd/timesyncd.conf。 これは、古い NTP サービスや chronyd サービスよりも有効なオプションが少ない単純なファイルです。 私の Fedora VM 上のこのファイルの内容 (追加の変更なし) は次のとおりです。

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

コメント以外に含まれる唯一のセクションは [Time] です。 他の行はすべてコメントアウトされています。 これらはデフォルト値であり、(理由がない限り) 変更しないでください。 NTP= 行で NTP タイム サーバーが定義されていない場合、Fedora はデフォルトでフォールバック Fedora タイム サーバーを使用します。 通常、タイムサーバーを追加します。

NTP=myntpserver

timesync の実行中

次のように systemd-timesyncd を起動してアクティブにすることができます。

[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
[root@testvm2 ~]# systemctl start systemd-timesyncd.service
[root@testvm2 ~]#

ハードウェアクロックの設定

timesyncd を実行した後の状況は次のようになります。

[root@testvm2 systemd]# timedatectl
               Local time: Sat 2020-05-16 14:34:54 EDT  
           Universal time: Sat 2020-05-16 18:34:54 UTC  
                 RTC time: Sat 2020-05-16 14:34:53      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes                          
              NTP service: active                      
          RTC in local TZ: no    

最初は、RTC と現地時間 (EDT) の差は XNUMX 秒未満ですが、次の数日間でその差はさらに数秒増加します。 RTC にはタイム ゾーンの概念がないため、timedatectl コマンドは比較を実行して正しいタイム ゾーンを決定する必要があります。 RTC 時間が現地時間と正確に一致しない場合は、現地のタイムゾーンとも一致しません。

さらに詳しい情報を求めて、systemd-timesync のステータスを確認したところ、次のことがわかりました。

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 822 (systemd-timesyn)
     Status: "Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org)."
      Tasks: 2 (limit: 10365)
     Memory: 2.8M
        CPU: 476ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─822 /usr/lib/systemd/systemd-timesyncd

May 16 09:57:24 testvm2.both.org systemd[1]: Starting Network Time Synchronization...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#

システム時間が設定されていないか、リセットされたことを示すログ メッセージに注目してください。 Timesync サービスは、タイムスタンプに基づいてシステム時刻を設定します。 タイムスタンプは timesync デーモンによって維持され、同期が成功するたびに作成されます。

timedatectl コマンドには、システム クロックからハードウェア クロックの値を取得する方法がありません。 コマンドラインに入力された値からのみ時刻と日付を設定できます。 hw Clock コマンドを使用して、RTC をシステム時間と同じ値に設定できます。

[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
               Local time: Mon 2020-05-18 13:56:46 EDT  
           Universal time: Mon 2020-05-18 17:56:46 UTC  
                 RTC time: Mon 2020-05-18 13:56:46      
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes                          
              NTP service: active                      
          RTC in local TZ: yes

--localtime オプションは、ハードウェア クロックに UTC ではなく現地時間を表示するように指示します。

そもそもなぜ RTC が必要なのでしょうか?

NTP を実装すると、起動時にシステム クロックが設定されます。 では、なぜ RTC なのでしょうか? これは完全に正しいわけではありません。これは、タイム サーバーにネットワーク接続している場合にのみ発生します。 ただし、多くのシステムは常にネットワーク接続にアクセスできるわけではないため、Linux がシステム時刻を設定するためにハードウェア クロックを使用すると便利です。 これは、リアルタイムからずれる可能性がありますが、時間を手動で設定するよりも優れています。

まとめ

この記事では、日付、時刻、タイムゾーンを操作するためのいくつかのツールをレビューしました。 systemd-timesyncd ツールは、ローカル ホストの時刻を NTP サーバーと同期できる NTP クライアントを提供します。 ただし、systemd-timesyncd はサーバー サービスを提供しないため、ネットワーク上に NTP サーバーが必要な場合は、Chrony などの他のサーバーをサーバーとして使用する必要があります。

私はネットワーク上のどのサービスでも単一の実装を使用することを好むため、Chrony を使用しています。 ローカル NTP サーバーが必要ない場合、またはサーバーとして Chrony を使用し、SNTP クライアントとして systemd-timesyncd を使用しても構わない場合。 結局のところ、systemd-timesyncd の機能に満足している場合は、クライアントとして Chrony の追加機能を使用する必要はありません。

もう XNUMX つの注意: NTP を実装するために systemd ツールを使用する必要はありません。 古いバージョンの ntpd、Chrony、または別の NTP 実装を使用できます。 結局のところ、systemd は多数のサービスで構成されています。 それらの多くはオプションであるため、それらをオフにして代わりに別のものを使用できます。 これは巨大な一枚岩のモンスターではありません。 systemd やその一部が気に入らないかもしれませんが、情報に基づいた決定を下す必要があります。

私は systemd の NTP 実装が好きですが、私のニーズにより適しているため、Chrony の方が好きです。 それは Linux です、ベイビー -)

広告の権利について

VDSina が提供する あらゆるタスクに対応するサーバー、自動インストール用のオペレーティング システムの膨大な選択肢、独自の OS をインストールすることが可能 ISO、 快適 コントロールパネル 独自の開発と日払い。 間違いなく時代を超越した永遠のサーバーがあることを思い出してください 😉

出所： habr.com