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

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