次のコマンドを使用して、Amazon Linux（Centos）サーバーでタイムゾーンを設定します。
ls -al /etc/localtime
-rw-r--r-- 1 root root 118 25 dec 2012 /etc/localtime
sudo mv /etc/localtime /etc/localtime.bak
sudo ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
これにより、現地時間ファイルがバックアップされるため、時間が正しい時間帯に設定されているかどうかを確認できます。最新の時刻がデフォルト値に復元されました。 bakファイルはまだそこにあるので、過去に時間を変更したことがわかります。
カーネルアップデートのためですか？
時間が変わらない理由は何であり、これを保証する方法はありますか？
修正する
更新された現地時間ファイルの時間は次のとおりです。
$ ls -al /etc/localtime
-rw-r--r-- 1 root root 118 25 jun 19:05 /etc/localtime
/var/log/yum.log を見ると、次のようになります。
Jun 25 19:05:27 Updated: glibc-common-2.17-55.143.amzn1.x86_64
Jun 25 19:05:30 Updated: glibc-2.17-55.143.amzn1.x86_64
Jun 25 19:05:31 Updated: libtiff-4.0.3-20.20.amzn1.x86_64
Jun 25 19:05:31 Updated: glibc-headers-2.17-55.143.amzn1.x86_64
Jun 25 19:05:31 Updated: subversion-libs-1.8.11-1.50.amzn1.x86_64
Jun 25 19:05:32 Updated: subversion-1.8.11-1.50.amzn1.x86_64
Jun 25 19:05:32 Updated: glibc-devel-2.17-55.143.amzn1.x86_64
Jun 25 19:05:32 Updated: libtiff-devel-4.0.3-20.20.amzn1.x86_64
Jun 25 19:05:32 Updated: python26-jmespath-0.7.1-1.9.amzn1.noarch
Jun 25 19:05:32 Updated: python27-jmespath-0.7.1-1.9.amzn1.noarch
Jun 25 19:05:33 Updated: glibc-2.17-55.143.amzn1.i686
だから私はそれらの1つがこれをしたと思う。おそらくglibcアップデートの1つではないかと思います。
答え1
ls -l /etc/localtime変更がいつ発生したかを確認してください。そして、/var/log/audit/audit.logなどのログを見て、/var/log/secureその時点で何が起こったのかを調べてください。
今systemd引き継がれ、/etc/localtimeコマンドがあります。
timedatectl set-timezone <zone>
ファイルを変更することもできます。またsystemd-timedated.service、データベースバスサービスタイムゾーンを変更してください。 systemd ログも表示できます。
sudo journalctl -l|grep timedate
次のコマンドを実行して、rpmをインストールしたときに実行されるスクリプトを見つけることができます。
rpm -q --scripts glibc
たとえば、glibcの場合です。auditファイルの監視をインストール、開始、および設定して、ファイルの変更を記録できます。
sudo auditctl -w /etc/localtime -k mymarker
次にログを確認します。
sudo ausearch -k mymarker
を含むすべてのルールを削除しますsudo auditctl -D。ファイルを開いたり変更したりしたすべてのプロセスに関する情報を取得できますが、シェルスクリプトからインポートした場合は、コマンドがorであるため、rmあまり役に立ちませんln。
timedatectl set-timezoneおそらく、タイムゾーンを直接接続するのではなくタイムゾーンを変更した場合は、追加のアップデートではこれを変更せずに受け入れるように動作しました。