ローカルタイムをJSTなどに設定しているAmazon Linuxで、glibcをupdateするとローカルタイムが元の設定に戻るという現象がおきることがあります。
これは、glibcの更新時に/etc/localtimeが書き換わってしまうからです。
よくあるトラブルとして、AutoScaleなどでインスタンスが起動したタイミングでcloud-initのsecurity updateが自動で走り、glibcが依存モジュールとして一緒に更新され、localtimeが意図せず書き換わったりします。
実験
というわけで、やってみました。
今回AMIは、amzn-ami-hvm-2014.09.1.x86_64-ebs (ami-4985b048)を使います。
glibcのパッケージは、glibc.x86_64 0:2.17-55.87.amzn1からglibc.x86_64 0:2.17-55.92.amzn1に更新します。
[ec2-user@ip-10-0-0-170 ~]$ date # UTC
2015年 1月 9日 金曜日 10:59:00 UTC
[ec2-user@ip-10-0-0-170 ~]$ cat /etc/sysconfig/clock # ハードウェアクロックの確認
ZONE="UTC"
UTC=true
[ec2-user@ip-10-0-0-169 ~]$ strings /etc/localtime # ローカルタイムの確認
TZif2
TZif2
UTC0
[ec2-user@ip-10-0-0-170 ~]$ sudo mv /etc/localtime{,.UTC} # バックアップ
[ec2-user@ip-10-0-0-170 ~]$ sudo ln -s /usr/share/zoneinfo/Japan /etc/localtime
# localtimeをJapanに設定
[ec2-user@ip-10-0-0-170 ~]$ date # JSTに設定されていることを確認
2015年 1月 9日 金曜日 19:59:00 JST
[ec2-user@ip-10-0-0-170 ~]$ sudo yum update glibc -y # glibcのアップデート
読み込んだプラグイン:priorities, update-motd, upgrade-helper
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ glibc.x86_64 0:2.17-55.87.amzn1 を 更新
--> 依存性の処理をしています: glibc = 2.17-55.87.amzn1 のパッケージ: glibc-common-2.17-55.87.amzn1.x86_64
---> パッケージ glibc.x86_64 0:2.17-55.92.amzn1 を アップデート
--> トランザクションの確認を実行しています。
---> パッケージ glibc-common.x86_64 0:2.17-55.87.amzn1 を 更新
---> パッケージ glibc-common.x86_64 0:2.17-55.92.amzn1 を アップデート
--> 依存性解決を終了しました。
(略)
更新:
glibc.x86_64 0:2.17-55.92.amzn1
依存性を更新しました:
glibc-common.x86_64 0:2.17-55.92.amzn1
完了しました!
[ec2-user@ip-10-0-0-170 ~]$ date # UTC!?
2015年 1月 9日 金曜日 10:59:14 UTC
[ec2-user@ip-10-0-0-170 ~]$ diff /etc/localtime /usr/share/zoneinfo/Japan
バイナリー・ファイル/etc/localtimeと/usr/share/zoneinfo/Japanは違います
[ec2-user@ip-10-0-0-170 ~]$ strings /etc/localtime # localtimeがUTCになっている
TZif2
TZif2
UTC0
glibcをアップデートすると、/etc/localtimeがUTCに戻っていることが確認できます。
どうするか
Amazon Linuxの時刻を現地時間に変更する方法が公式ドキュメントに書かれています。
ドキュメントにしたがうと、/etc/localtimeの差し替えと、/etc/sysconfig/clockのZONEを書き換えれば良さそうです。
やってみました。
[ec2-user@ip-10-0-0-169 ~]$ date # UTC確認
2015年 1月 9日 金曜日 11:33:55 UTC
[ec2-user@ip-10-0-0-169 ~]$ cat /etc/sysconfig/clock # ZONE確認
ZONE="UTC"
UTC=true
[ec2-user@ip-10-0-0-169 ~]$ strings /etc/localtime # localtime確認
TZif2
TZif2
UTC0
[ec2-user@ip-10-0-0-169 ~]$ sudo mv /etc/localtime{,.UTC} # backup
[ec2-user@ip-10-0-0-169 ~]$ sudo ln -s /usr/share/zoneinfo/Japan /etc/localtime # localtimeをJapanに
[ec2-user@ip-10-0-0-169 ~]$ date # JSTの確認
2015年 1月 9日 金曜日 20:34:36 JST
[ec2-user@ip-10-0-0-169 ~]$ sudo sed -i s/ZONE=\"UTC\"/ZONE=\"Japan\"/g /etc/sysconfig/clock # ZONEを書き換え
[ec2-user@ip-10-0-0-169 ~]$ cat /etc/sysconfig/clock # ZONEがJapanであることを確認
ZONE="Japan"
UTC=true
[ec2-user@ip-10-0-0-169 ~]$ sudo yum update glibc -y # glibcの更新
読み込んだプラグイン:priorities, update-motd, upgrade-helper
(略)
更新:
glibc.x86_64 0:2.17-55.92.amzn1
依存性を更新しました:
glibc-common.x86_64 0:2.17-55.92.amzn1
完了しました!
[ec2-user@ip-10-0-0-169 ~]$ date # JSTのまま！
2015年 1月 9日 金曜日 20:36:42 JST
[ec2-user@ip-10-0-0-169 ~]$ strings /etc/localtime # localtimeも変更なし
TZif2
JCST
TZif2
JCST
JST-9
まとめ
Amazon Linuxの時刻設定を適切に行えば、glibcが更新されてもローカルタイムに影響がないことがわかりました。再起動やAMI化やする際には、/etc/localtimeの変更だけでなく、/etc/sysconfig/clockにZONEの設定を忘れずにしておきたいですね。
残る疑問
いろいろな方がこの地雷を踏んでいるので、ググれば先人の知恵がでてくる（ありがたいです）のですが、
こんなかんじで、ZONEだけでなくUTC=Falseに設定するというものがありました。
ZONE="Japan"
UTC=False
自分もいままでUTC=Falseにしてたのですが、上記の結論的には、ZONEの設定をすればUTC=trueでglibcが更新されても影響を受けなさそうです。公式ドキュメントでも時刻設定にUTC=trueの設定を変更してませんでしたし、この値って変更しなくてもよいのではという結論になりつつあります。
Xenの上で動くような仮想環境でハードウェアクロックがどのように設定され、UTC=falseにするとどのような弊害が起こりうるのか、いまいちイメージが湧いてこないというのが正直なところです。
RTCもないようなので、インスタンス起動時にハイパーバイザーからハードウェアクロックもらってシステムクロックに反映しているという認識でいいのだろうか。。。
[ec2-user@ip-10-0-0-169 ~]$ sudo hwclock --debug
hwclock from util-linux 2.23.2
hwclock: /dev/rtc を open できません: そのようなファイルやディレクトリはありません
利用可能なクロックインターフェイスが見つかりません。
hwclock: Cannot access the Hardware Clock via any known method.
誰か教えて下さい m(__)m
参考
http://www.atmarkit.co.jp/ait/articles/0812/26/news120.html
http://park12.wakwak.com/~eslab/pcmemo/clock/clock3.html