ローカルでハードなクロックの話

Linuxやシステム管理に詳しい人からしてみれば何だそんなこと、というレベルの話ですが…。
何分ど素人が備忘録的に書いている記事なので、間違い等ありましたら何卒ご容赦を。

とある仮想サーバ（CentOS 6.5）でglibcのyum updateと機能試験を行い、問題無しと判断して実環境で同じことを行ったところ何台かのサーバの時間設定がJSTからUTCに戻る事態となり、軽く冷や汗をかきました。調べてみたところCentOS Bug Trackerにこんな投稿が。CentOS4の頃の情報ですが、まさにこれです…。

0002085: Yum updates reset /etc/localtime causing the time to be incorrect - CentOS Bug Tracker

There is a trigger script (/usr/sbin/tzdata-update) for the glibc-common package which runs whenever the tzdata package is updated. This in turn gets its zone information from /etc/sysconfig/clock. You should edit that file instead of just replacing /etc/localtime.

This is the way the upstream distribution does it and isn't -- good idea or not -- a CentOS bug.

glibc-commonの更新の際に一緒にtzdata-update（タイムゾーンの更新）が実行されてしまうので/etc/localtime（ローカルタイム）の内容が/etc/sysconfig/clock（ハードウェアクロック）で書き換わる。だから/etc/sysconfig/clockも設定する必要がある、とのことです。

cp -p /usr/share/zoneinfo/Japan /etc/localtime

strings /etc/localtime
TZif2
TZif2
JST-9

今までずっとこういう感じでローカルタイムを設定すればOKだと思っていたのですが

less /etc/sysconfig/clock
ZONE="Asia/Tokyo"

このようにハードウェアクロックも正しく設定してあるか確認する必要があるのですね。

大事には至りませんでしたが、設計した側の意図を考えず設定を弄ることの危うさを認識させられました。「ググる前にmanページを読め」というのは本当に金言だと思います。

…蛇足ながら、なぜUTCに戻るサーバと戻らないサーバがあったかと言いますと

某クラウドのCentOSテンプレートがカスタムされてZONE="Asia/Tokyo"がデフォルトになっていた
↓
そのテンプレートを元に構築した環境をスナップショットにして、検証環境を構築
↓
検証環境でglibcの更新と試験を行い、問題無いと判断
↓
ところが、CentOSのバージョンが上がった際にテンプレートが更新され設定がデフォルトのZONE="UTC"に変更された（というか、こっちが正しい）
↓
更新作業を行ったところ、ある時期を境に新しく作ったサーバ群が全部UTCに戻る
↓
／(^o^)＼

というのが事の真相だったようです。

人生もそうですが、便利だから、楽だから、とお仕着せで物事をするといつか痛い目に合うものです…。

●参考文献

glibcを更新しても大丈夫な「正しい」タイムゾーンの設定方法 - めもおきば
http://d.hatena.ne.jp/nekoruri/20150130/glibclocaltime

28.1.6. /etc/sysconfig/clock
https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-sysconfig-clock.html

Linux時刻管理の仕組みと設定 (1/4)
http://www.atmarkit.co.jp/ait/articles/0812/26/news120.html