GNU/Linux >> Linux の 問題 >  >> Linux

systemdでコンピューターの時刻と日付を制御する

ほとんどの人は時間に関心があります。私たちは朝の儀式を行い、通勤し(最近の私たちの多くは短い旅行です)、昼食のために休憩し、プロジェクトの締め切りに間に合い、誕生日や休日を祝い、飛行機に乗るなど、さまざまなことに間に合います。 。

私たちの中には取りつかれている人もいます 時間とともに。私の時計は太陽電池式で、コロラド州フォートコリンズにある米国国立標準技術研究所(NIST)から、そこにあるWWVB時報ラジオ局を介して正確な時刻を取得しています。時報は、同じくフォートコリンズにある原子時計に同期されます。 Fitbitは携帯電話と同期し、携帯電話はNetwork Time Protocol(NTP)サーバーと同期され、最終的には原子時計と同期されます。

コンピューターにとって時間が重要な理由

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

私たちの電話、タブレット、車、GPSシステム、およびコンピューターはすべて、正確な時刻と日付の設定を必要とします。コンピューターのデスクトップの時計を正しくしたいので、ローカルのカレンダーアプリケーションを使用して、正しい時刻にリマインダーをポップアップできます。正しい時刻は、SystemVcronジョブとsystemdタイマーが正しい時刻にトリガーされることも保証します。

正しい時刻はロギングにとっても重要であるため、時刻に基づいて特定のログエントリを見つけるのは少し簡単です。一例として、私はかつてノースカロライナ州の電子メールシステムのDevOps(当時はそのように呼ばれていませんでした)で働いていました。以前は、1日あたり2,000万通以上のメールを処理していました。問題のコンピューターが正確な時刻を保持している場合、一連のサーバーを介した電子メールの追跡を追跡したり、地理的に分散したホスト上のログファイルを使用してイベントの正確なシーケンスを決定したりする方がはるかに簡単です。

複数回

Linuxホストには、システム時間とRTC時間の2つの考慮事項があります。 RTCはリアルタイムクロックの略で、システムハードウェアクロックの派手で特に正確な名前ではありません。

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

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

システム時間は、オペレーティングシステムが認識している時間です。これは、dateからの出力でデスクトップのGUIクロックに表示される時刻です。 コマンド、ログのタイムスタンプ、およびファイルアクセス、変更、変更時間。

rtc マニュアルページには、RTCとシステムクロックおよびRTCの機能に関するより完全な説明が含まれています。

NTPはどうですか?

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

その他のLinuxリソース

  • Linuxコマンドのチートシート
  • 高度なLinuxコマンドのチートシート
  • 無料のオンラインコース:RHELの技術概要
  • Linuxネットワーキングのチートシート
  • SELinuxチートシート
  • Linuxの一般的なコマンドのチートシート
  • Linuxコンテナとは何ですか?
  • 最新のLinux記事

階層の下位(つまり、階層番号が大きい)のタイムサーバーまたはクライアントからの時間要求がプライマリ参照サーバーを圧倒するのを防ぐために、数千のパブリックNTP階層2サーバーが開いており、すべてのユーザーが使用できます。 NTPサーバーを必要とする多数のホストを持つ多くの組織とユーザー(私を含む)は、独自のタイムサーバーをセットアップすることを選択するため、1つのローカルホストのみが2層または3層のタイムサーバーにアクセスします。次に、ローカルタイムサーバーを使用するようにネットワーク内の残りのホストを構成します。私のホームネットワークの場合、それはストラタム3サーバーです。

NTP実装オプション

元のNTP実装はntpdです 、そして2つの新しい chronydが加わりました およびsystemd-timesyncd 。 3つすべてが、ローカルホストの時刻をNTPタイムサーバーと同期させます。 systemd-timesyncdサービスは、chronydほど堅牢ではありませんが、ほとんどの目的には十分です。 RTCの同期が大幅にずれている場合は、大きなタイムジャンプを実行できます。また、ローカルシステムの時間が少しずれている場合は、システム時間を徐々に調整してNTPサーバーとの同期を維持できます。 systemd-timesyncサービスをタイムサーバーとして使用することはできません。

Chronyは、chronydデーモンとchronycと呼ばれるコマンドラインインターフェイスの2つのプログラムを含むNTP実装です。前回の記事で説明したように、Chronyには、主に次のような多くの環境に最適な機能がいくつかあります。

  • Chronyは、古いntpdサービスよりもはるかに高速にタイムサーバーに同期できます。これは、常時稼働しないラップトップやデスクトップに適しています。
  • ホストが休止状態またはスリープモードに入ったとき、または負荷が低いときにクロック速度を遅くする周波数ステッピングによってクロック速度が変化したときなど、変動するクロック周波数を補正できます。
  • 断続的なネットワーク接続と帯域幅の飽和を処理します。
  • ネットワーク遅延と遅延を調整します。
  • 最初の時刻同期後、Chronyは時計を停止しません。これにより、多くのシステムサービスとアプリケーションの安定した一貫した時間間隔が保証されます。
  • Chronyは、ネットワークに接続していなくても機能します。この場合、ローカルホストまたはサーバーを手動で更新できます。
  • ChronyはNTPサーバーとして機能できます。

明確にするために、NTPは、Chronyまたはsystemd-timesyncd.serviceのいずれかを使用してLinuxホストに実装されるプロトコルです。

NTP、Chrony、およびsystemd-timesyncd RPMパッケージは、標準のFedoraリポジトリーで利用できます。 systemd-udev RPMは、ルールベースのデバイスノードおよびカーネルイベントマネージャーであり、デフォルトでFedoraとともにインストールされますが、有効にはなりません。

3つすべてをインストールして切り替えることができますが、それは面倒であり、面倒な価値はありません。 Fedora、CentOS、およびRHELの最新リリースは、デフォルトの計時実装としてNTPからChronyに移行し、systemd-timesyncdもインストールしています。 Chronyはうまく機能し、NTPサービスよりも優れたインターフェースを提供し、より多くの情報を提供し、制御を強化します。これらはすべて、システム管理者にとっての利点です。

他のNTPサービスを無効にする

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

 [root @ testvm1〜]#systemctl disable chronyd; systemctl stop chronyd 
/etc/systemd/system/multi-user.target.wants/chronyd.serviceを削除しました。
[root@ testvm1〜]#

停止していて無効になっていることを確認します:

 [root @ testvm1〜]#systemctl status chronyd 
●chronyd.service-NTPクライアント/サーバー
ロード済み:ロード済み(/usr/lib/systemd/system/chronyd.service;無効;ベンダープリセット:有効)
アクティブ:非アクティブ(デッド)
ドキュメント:man:chronyd(8)
man:chrony.conf(5)
[root @ testvm1〜]#
開始する前にステータスを確認してください

systemd timesyncのステータスは、systemdがNTPサービスを開始したかどうかを示します。 systemd NTPをまだ開始していないため、timesync-status コマンドはデータを返しません:

 [root @ testvm1〜]#timedatectl timesync-status 
サーバーのクエリに失敗しました:リモートピアをアクティブ化できませんでした。

しかし、まっすぐなstatus リクエストはいくつかの重要な情報を提供します。たとえば、timedatectl 引数またはオプションのないコマンドは、statusを意味します デフォルトのサブコマンド:

 [root @ testvm1〜]#timedatectl status 
現地時間:金2020-05-15 08:43:10 EDT
ユニバーサル時間:金2020-05-15 12:43:10 UTC
RTC時間:金2020-05-15 08:43:08
タイムゾーン:America / New_York(EDT、-0400)
同期:no />非アクティブ
ローカルTZのRTC:はい

警告:システムは、ローカルタイムゾーンのRTC時間を読み取るように構成されています。
タイムゾーンの変更や夏時間の調整など、さまざまな問題が発生します。
RTC
時刻は更新されず、外部の機能に依存して更新されます。
可能であれば、UTCでRTCを使用して
'timedatectlset-local-rtc0'を呼び出します。
[root @ testvm1〜]#

これにより、ホストの現地時間、UTC時間、およびRTC時間が返されます。これは、システム時刻がAmerica/New_Yorkに設定されていることを示しています。 タイムゾーン(TZ )、RTCはローカルタイムゾーンの時刻に設定されており、NTPサービスはアクティブではありません。 RTC時間は、システム時間から少しずれ始めています。これは、クロックが同期されていないシステムでは正常です。ホストでのドリフトの量は、システムが最後に同期されてからの時間と、単位時間あたりのドリフトの速度によって異なります。

RTCに現地時間を使用することについての警告メッセージもあります。これは、タイムゾーンの変更と夏時間の調整に関連しています。変更が必要なときにコンピューターの電源がオフになっている場合、RTC時間は変更されません。これは、24時間年中無休で電源がオンになっているサーバーやその他のホストでは問題になりません。また、NTP時刻同期を提供するサービスは、起動プロセスの早い段階でホストが適切な時刻に設定されていることを確認するため、完全に稼働する前に正しく設定されます。

タイムゾーンを設定する

通常、インストール手順中にコンピュータのタイムゾーンを設定し、変更する必要はありません。ただし、タイムゾーンを変更する必要がある場合があり、役立つツールがいくつかあります。 Linuxは、タイムゾーンファイルを使用して、ホストが使用しているローカルタイムゾーンを定義します。これらのバイナリファイルは、/usr/share/zoneinfoにあります。 ディレクトリ。私のタイムゾーンのデフォルトは、リンク/etc/localtime -> ../usr/share/zoneinfo/America/New_Yorkによって定義されています。 。ただし、タイムゾーンを変更するためにそれを知る必要はありません。

ただし、現在地の正式なタイムゾーン名を知っている必要があります。タイムゾーンをロサンゼルスに変更するとします:

 [root @ testvm2〜]#timedatectl list-timezones |コラム

アメリカ/ヨーロッパLa_Paz /ブダペスト
アメリカ/リマヨーロッパ/キシナウ
アメリカ/ Los_Angelesヨーロッパ/コペンハーゲン
アメリカ/マセイオヨーロッパ/ダブリン
アメリカ/マナグアヨーロッパ/ジブラルタル
アメリカ/マナウスヨーロッパ/ヘルシンキ

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

 [root @ testvm2〜]#date 
2020年5月19日火曜日04:47:49PMEDT
[root @ testvm2〜]#timedatectl set-timezone America / Los_Angeles
[root @ testvm2〜]#date
2020年5月19日火曜日01:48:23PMPDT
[root @ testvm2〜]#

これで、ホストのタイムゾーンをローカルのタイムゾーンに戻すことができます。

systemd-timesyncd

systemd timesyncデーモンは、systemdコンテキスト内で管理しやすいNTP実装を提供します。デフォルトでFedoraとUbuntuにインストールされ、デフォルトでUbuntuで起動されますが、Fedoraでは起動されません。他のディストリビューションについてはよくわかりません。あなたはあなたをチェックすることができます:

 [root@testvm1 ~]# systemctl status systemd-timesyncd 
systemd-timesyncdを構成します

systemd-timesyncdの構成ファイルは/etc/systemd/timesyncd.confです。 。これは、古いNTPサービスやchronydよりもオプションが少ない単純なファイルです。これが私のFedoraVM上のこのファイルのデフォルトバージョンの完全な内容です:

#このファイルはsystemdの一部です。

#systemdは自由ソフトウェアです。
#フリーソフトウェアファウンデーションによって公開されているGNU劣等一般公衆利用許諾契約書の条件に基づいて、再配布および/または変更することができます。
#ライセンスのバージョン2.1、または
#(オプションで)それ以降のバージョン。

#このファイルのエントリは、コンパイル時のデフォルトを示しています。
#変更できますこのファイルを編集して設定します。
#このファイルを削除するだけでデフォルトに戻すことができます。

#詳細については、timesyncd.conf(5)を参照してください。

[時間]
#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 
タイムシンクを開始

systemd-timesyncdの起動と有効化は、他のサービスとまったく同じです:

 [root @ testvm2〜]#systemctl enable systemd-timesyncd.service
作成されたsymlink/etc/systemd/system/dbus-org.freedesktop.timesync1.service→/usr/ lib / systemd / system / systemd -timesyncd.service。
作成された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を開始した後の私のシステムの1つは次のようになりました:

 [root @ testvm2 systemd]#timedatectl 
現地時間:Sat 2020-05-16 14:34:54 EDT
ユニバーサル時間:Sat 2020-05-16 18:34:54 UTC
RTC時間:Sat 2020-05-16 14:34:53
タイムゾーン:America / New_York(EDT、-0400)
システムクロック同期:はい/>
ローカルTZのRTC:いいえ

RTC時間は現地時間(EDT)から約1秒ずれており、この不一致は今後数日間でさらに数秒大きくなります。 RTCにはタイムゾーンの概念がないため、timedatectl コマンドは、どのタイムゾーンが一致するかを判断するために比較を行う必要があります。 RTC時刻が現地時間と正確に一致しない場合、現地時間帯にあるとは見なされません。

もう少し情報を探して、systemd-timesync.serviceのステータスを確認したところ、次のことがわかりました。

 [root @ testvm2 systemd]#systemctl status systemd-timesyncd.service 
●systemd-timesyncd.service-ネットワーク時刻の同期
ロード済み:ロード済み(/ usr / lib / systemd / system / systemd- timesyncd.service;有効;ベンダープリセット:無効)
アクティブ:Sat 2020-05-16 13:56:53 EDT以降アクティブ(実行中)。 18時間前
ドキュメント:man:systemd-timesyncd.service(8)
メインPID:822(systemd-timesyn)
ステータス: "タイムサーバー163.237.218.19:123(2 .fedora.pool.ntp.org)。 "
タスク:2(制限:10365)
メモリ:2.8M
CPU:476ms
CGroup:/system.slice/systemd -timesyncd.service
└─822/usr/ lib / systemd / systemd-timesyncd

5月16日09:57:24testvm2.both.orgsystemd [1]:ネットワーク時間同期の開始...
5月16日09:57:24testvm2.both.orgsystemd-timesyncd [822]:システムクロック時刻が設定されていないか、逆方向にジャンプし、記録されたタイムスタンプから復元しています:Sat 2020-05-16 13:56:53 EDT
5月16日13:56:53testvm2.both.orgsystemd [1]:ネットワーク時間同期を開始しました。
5月16日13:57:56testvm2.both.org systemd-timesyncd [822]:タイムサーバー163.237.218.19:123(2.fedora.pool.ntp.org)への初期同期。
[root @ testvm2 systemd]#

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

timedatectl コマンドには、システムクロックからハードウェアクロックの値を設定する機能はありません。コマンドラインで入力した値からのみ日時を設定できます。ただし、hwclockを使用して、RTCをシステム時間と同じ値に設定できます。 コマンド:

 [root @ testvm2〜]#/ sbin / hwclock --systohc --localtime 
[root @ testvm2〜]#timedatectl
現地時間:Mon 2020-05-18 13:56:46 EDT
ユニバーサル時間:Mon 2020-05-18 17:56:46 UTC
RTC時間:Mon 2020-05-18 13:56:46
またはY:Tゾーン、-0400)
同期されたシステムクロック:はい
NTPサービス:アクティブ

--localtime オプションを使用すると、ハードウェアクロックがUTCではなく現地時間に設定されます。

本当にRTCが必要ですか?

NTPの実装では、起動シーケンス中にシステムクロックが設定されるため、RTCは必要ですか?タイムサーバーへのネットワーク接続がある限り、実際にはそうではありません。ただし、多くのシステムはネットワーク接続にフルタイムでアクセスできないため、ハードウェアクロックは、Linuxがそれを読み取ってシステム時間を設定できるようにするために役立ちます。これは、実際の時刻からずれている場合でも、手動で時刻を設定するよりも優れたソリューションです。

概要

この記事では、日付、時刻、およびタイムゾーンを管理するためのいくつかのsystemdツールの使用について説明しました。 systemd-timesyncdツールは、NTPサーバーと同期したローカルホストで時間を維持できる適切なNTPクライアントを提供します。ただし、systemd-timesyncdはサーバーサービスを提供しないため、ネットワーク上にNTPサーバーが必要な場合は、サーバーとして機能するためにChronyなどの他のものを使用する必要があります。

ネットワーク内のすべてのサービスに対して単一の実装を使用することを好むため、Chronyを使用します。ローカルのNTPサーバーが必要ない場合、またはサーバーのChronyとクライアントのsystemd-timesyncdの処理を気にせず、Chronyの追加機能が必要ない場合は、systemd-timesyncdがNTPクライアントのサービス可能な選択肢です。 。

私が言いたいもう一つのポイントがあります:あなたはNTPの実装のためにsystemdツールを使う必要はありません。古いntpd、Chrony、またはその他のNTP実装を使用できます。 systemdは多数のサービスで構成されています。それらの多くはオプションであるため、無効にしたり、代わりに他の何かを使用したりできます。一部の人がそれを明らかにするのは、巨大なモノリシックモンスターではありません。 systemdまたはその一部が気に入らなくても構いませんが、十分な情報に基づいて決定する必要があります。

systemdによるNTPの実装は嫌いではありませんが、自分のニーズをよりよく満たすため、Chronyの方がはるかに好きです。そしてそれがLinuxのすべてです。

リソース

インターネット上にはsystemdに関する多くの情報がありますが、その多くは簡潔で、鈍感で、誤解を招くものですらあります。この記事に記載されているリソースに加えて、次のWebページでは、systemdの起動に関するより詳細で信頼性の高い情報を提供しています。

  • Fedora Projectには、systemdに関する優れた実用的なガイドがあります。 systemdを使用してFedoraコンピューターを構成、管理、および保守するために知っておく必要のあるほとんどすべてが含まれています。
  • Fedora Projectには、古いSystemVコマンドを同等のsystemdコマンドと相互参照する優れたチートシートもあります。
  • systemdの詳細な技術情報とその作成理由については、Freedesktop.orgのsystemdの説明をご覧ください。
  • Linux.comの「Moresystemdfun」は、より高度なsystemd情報とヒントを提供します。

また、systemdの設計者であり主要な開発者であるLennart Poetteringによる、Linuxシステム管理者向けの一連の詳細な技術記事もあります。これらの記事は2010年4月から2011年9月の間に書かれましたが、当時と同じように関連性があります。 systemdとそのエコシステムについて書かれた他のすべての優れた点の多くは、これらの論文に基づいています。

  • PID1を再考する
  • 管理者向けsystemd、パートI
  • 管理者向けsystemd、パートII
  • 管理者向けsystemd、パートIII
  • 管理者向けsystemd、パートIV
  • 管理者向けsystemd、パートV
  • 管理者向けsystemd、パートVI
  • 管理者向けsystemd、パートVII
  • 管理者向けsystemd、パートVIII
  • 管理者向けsystemd、パートIX
  • 管理者向けsystemd、パートX
  • 管理者向けsystemd、パートXI

Linux
  1. Linux システムの再起動日時を表示する方法

  2. Linux で C++ を使用してシステムの日付と時刻を設定する

  3. Linux で現在の日付と時刻の名前のファイルを作成する方法

  1. スクリプトとscriptreplayを使用して端末を記録します

  2. [解決済み]:仮想マシンのクロックがホストマシンと同期するのを防ぎ、独立したクロック時間を設定するにはどうすればよいですか?

  3. 特定の日付のファイルを検索して削除する

  1. Lokiとfzfでシェルの履歴をレベルアップ

  2. 日付と時刻を含む Linux コマンド履歴

  3. Linux でのシステム起動日時の取得