ん?デフォルトのVMなのにAzureの日付がおかしい・・
昼下がりの午後3時ごろ、Azure上のMarketPlaceにあるCentOSのイメージを利用してVMを作成し、ディスク監視のcronの登録をすすめていたのですが、なぜか出力結果が下記に・・
[user@VM ~]$ df -h | grep ramdisk | awk '{ print strftime("%H%M"),$5 }'
0600 0%
0600
って... 朝やんけ
現在午後3時、24時間表記では15時。
strftimeで%H%Mでフォーマット定義しているおり、
HH(時間)MM(分)形式で出力されることを想定していたのですが・・
(期待値は1500
)
初回の時刻同期でいていないのかなぁと思いながら
dateしてみると・・
dateの確認
$ date
Fri Dec 7 05:32:42 UTC 2018
...お、おうそういうことか。
時刻同期の問題ではなく
UTC
だったのね。。
UTCとJSTの時差は+9時間
6(標準時間)+9(時差)=15(日本時間)
で計算上もあってる・・
Azureはグローバルな環境だからタイムゾーンは日本時間(JST)ではなくUTCになっているんだなぁとすごいなぁと
最初思ったのですが、
ふとよく考えればオンプレの場合は何も考えずにルーチンで設定変更作業してるだけかw
と一人突っ込みしつつ設定変更を一応ググる。
設定変更方法の調査
検索してみた結果特にポータル等から設定するわけではなく
Linux側での設定変更でOKなよう。
調査の過程で時刻同期周りも気になって調べましたが、どうやら時刻の同期についてはこちらのような形で
NTPで行っているようではない様子。今回の本題からはずれるので別途調査します。
なんとなくIaaSって何でもやってくれるようなイメージにかられますが、
ラッキングや仮想マシンの払い出しに該当する作業を知らないだれかがしてくれるだけで、
サーバー観点からみるとOSからの設定はオンプレと同じっていうイメージそのままのようです。
日本時間(JST)へ設定変更
そんなこんな考えながら下記良記事みつけたのでこちらに従ってタイムゾーンを変更していきます。
$ timedatectl
Local time: Fri 2018-12-07 05:46:15 UTC
Universal time: Fri 2018-12-07 05:46:15 UTC
RTC time: Fri 2018-12-07 05:46:15
Time zone: Etc/UTC (UTC, +0000)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
$ sudo timedatectl set-timezone Asia/Tokyo
$ sudo timedatectl set-local-rtc 0
$ timedatectl
Local time: Fri 2018-12-07 14:46:47 JST
Universal time: Fri 2018-12-07 05:46:47 UTC
RTC time: Fri 2018-12-07 05:46:48
Time zone: Asia/Tokyo (JST, +0900)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
もう一度dateも確認すると
$ date
Fri Dec 7 15:00:02 JST 2018
おぉぉぉ。
dfの結果も下記のようになりログ取れそうです
$ df -h | grep ramdisk | awk '{ print strftime("%H%M"),$5 }'
1510 0%
(おまけ)
今回の環境はIaaSでしたがPaaSでも同様なようで下記のようなtipsを発見。
PaaSについても同様の現象が発生するようなので注意が必要です。
[Azureへデプロイ後に陥るトラブルのNo.1は時間関係(UTC)だと思う]
(http://shin21.hatenablog.com/entry/2016/05/05/203000)