Hatena::ブログ(Diary)

(ひ)メモ このページをアンテナに追加 RSSフィード

2016-12-14 (Wed)

hardware clockがずれる件と 11 minute mode

localtimeにしていたhardware clockをなんとなくUTCにしてみたら10分ぐらいで元に戻っちゃうというお話です。環境は Ubuntu 16.04 です。

結局、reboot しないとダメだったんですが、いい方法あったら教えてください><



hardware clockがlocaltimeになっているかUTCになっているかは、timedatectl の "RTC time" や "RTC in local TZ" のところを見るか、

### UTCの場合
$ sudo timedatectl
      Local time: Wed 2016-12-14 19:19:46 JST
  Universal time: Wed 2016-12-14 10:19:46 UTC
        RTC time: Wed 2016-12-14 10:19:46 # ココ
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no # ココ
      DST active: n/a

### localtimeの場合
$ sudo timedatectl
      Local time: Wed 2016-12-14 19:34:20 JST
  Universal time: Wed 2016-12-14 10:34:20 UTC
        RTC time: Wed 2016-12-14 19:34:20 # ココ
        Timezone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: yes # ココ
      DST active: n/a

Warning: The RTC is configured to maintain time in the local time zone. This
         mode is not fully supported and will create various problems with time
         zone changes and daylight saving adjustments. If at all possible use
         RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

hwclock --show --debug でも確認できます。

### UTCの場合
$ sudo hwclock --show --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1478666918 seconds after 1969
Last calibration done at 1478666918 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time. # ココ
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/12/14 10:36:58
Hw clock time : 2016/12/14 10:36:58 = 1481711818 seconds since 1969
Wed Dec 14 19:36:58 2016  -0.074581 seconds

### localtimeの場合
$ sudo hwclock --show --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1481708948 seconds after 1969
Last calibration done at 1481708948 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time. # ココ
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/12/14 19:37:03
Hw clock time : 2016/12/14 19:37:03 = 1481711823 seconds since 1969
Wed Dec 14 19:37:03 2016  -0.031894 seconds

hwclock --systohc --utc や timtdatectl set-local-rtc 0 で hardware clock を localtime から UTC に変更できるのですが、10分ぐらいするとなぜか元に戻っちゃいました。

これは hwclock(8) に依れば "11 minute mode" という、system clockがずれていないと信頼できるような環境で有益な、11分ごとにhardware clockをsystem clockの時刻に合わせるモードが原因でした。

"11 minute mode" が有効になっているかどうかは、ntptime の実行結果の status 行を見れば確認できます。ここにUNSYNCがなければ有効、あれば無効です。

### "11 minute mode" が有効になっている(=UNSYNCがない)
$ ntptime | grep status
  status 0x2001 (PLL,NANO),

### "11 minute mode" が無効になっている(=UNSYNCがある)
$ ntptime | grep status
  status 0x41 (PLL,UNSYNC),

もしくは adjtimex --print の実行結果の status の数値の 64 ビット目が0(STA_UNSYNC)ならば "11 minute mode" が有効になっていることを示します。


hwclock(8) にも書いてありますが、手元の環境でも ntpd を起動すると "11 minute mode" が有効になりました。(落とすと無効になる)


というわけで、ntpd を起動すると "11 minute mode" が有効になり kernel(?) が認識しているタイムゾーンと異なるのか、10分ぐらいすると hardware clock の時刻がずれてしまいました。

いろいろ

  • /etc/adjtime を消して hwclock --systohc --utc
  • timtdatectl set-local-rtc 0

やってみたんですが、解消できず、結局は ntpd を落として hardware clock を UTC にして reboot したら直りました。(起動後に ntpd を起動してももうずれない)

2016-10-04 (Tue)

MySQL 5.7のmysqld --initializeと鶏卵問題

MySQLのデータディレクトリの初期化にはこれまで mysql_install_db が使われてきましたが、MySQL 5.7からは mysqld --initialize を使うことが推奨されています。

mysqld --initialize は datadir 配下にファイルやサブディレクトリがあるとエラー終了します。


# mysqld --initialize --user=mysql
2016-10-04T11:39:01.313174Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2016-10-04T11:39:01.313222Z 0 [ERROR] Aborting

なので datadir をスッカラカンにして再度実行してみます。my.cnf はこんな内容で、datadir の下に tmpdir、InnoDBのデータとログのディレクトリがある構成です。

datadir  = /data/mysql
tmpdir   = /data/mysql/tmp
innodb_data_home_dir            = ibdata
innodb_log_group_home_dir       = iblog
# rm -fr /data/mysql/*
# mysqld --initialize --user=mysql
# echo $?
1
# cat /data/mysql/mysqld.err
mysqld: Can't create/write to file '/data/mysql/tmp/ibSY07SU' (Errcode: 2 - No such file or directory)
2016-10-04T11:41:18.876953Z 0 [ERROR] InnoDB: Unable to create temporary file; errno: 2
2016-10-04T11:41:18.876965Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2016-10-04T11:41:18.876971Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2016-10-04T11:41:18.876975Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2016-10-04T11:41:18.876980Z 0 [ERROR] Failed to initialize plugins.
2016-10-04T11:41:18.876983Z 0 [ERROR] Aborting

/data/mysql/tmp が存在しないので /data/mysql/tmp/ibSY07SU が作れずエラー終了しています。

InnoDBのデータ、ログディレクトリについても同様で、自動ではサブディレクトリを作ってくれません。

[ERROR] InnoDB: Operating system error number 2 in a file operation.
[ERROR] InnoDB: The error means the system cannot find the path specified.
[ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them.
[ERROR] InnoDB: File ibdata/ibdata1: 'create' returned OS error 71. Cannot continue operation
[ERROR] InnoDB: Cannot continue operation.
[ERROR] InnoDB: Operating system error number 2 in a file operation.
[ERROR] InnoDB: The error means the system cannot find the path specified.
[ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them.
[ERROR] InnoDB: File iblog/ib_logfile101: 'create' returned OS error 71.
[ERROR] InnoDB: Cannot create iblog/ib_logfile101
[ERROR] InnoDB: InnoDB Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again.
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Failed to initialize plugins.
[ERROR] Aborting

というわけで、初期化にはサブディレクトリが必要なわけですが、サブディレクトリがあると mysqld --initialize はエラー終了します。

_人人人人人人人人人人人人人人人人人人_

> どうすりゃいいねん!!!!!!! <

 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄



途方に暮れそうになりましたが、ドキュメントにちゃんと書いてありました。

As of MySQL 5.7.11, an existing data directory is permitted to be nonempty if every entry either has a name that begins with a period (.) or is named using an --ignore-db-dir option.

https://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html

というわけで、予め必要なサブディレクトリを作っておいて、必要なだけ --ignore-db-dir で繰り返しそれを指定すればOKです。

# rm -fr /data/mysql/*
# install -d -o mysql -g mysql -m 750 /data/mysql/{tmp,ibdata,iblog}
# mysqld --initialize  --user=mysql --ignore-db-dir=tmp --ignore-db-dir=ibdata --ignore-db-dir=iblog
# echo $?
0

2016-05-06 (Fri)

LXD 2.0でlive migrationしてみる

基本的には

に書いてある通りなんで、これの補足という形になります。


まず、live migrationを行う(ホストh1にあるコンテナc1をホストh2にlive migrationする場合)のにこのようなコマンドを実行すると

hirose31@h1$ lxc move c1 h2:

「error: Error transferring container data: websocket: bad handshake」というエラーで失敗し、以下のようにlocalの場合でもremote名を添えて実行すれば成功しました。

hirose31@h1$ lxc move h1:c1 h2:

従って、予め自ホストの分もremoteの登録が必要でした。

hirose31@h1$ lxc remote add h1 192.168.33.21
hirose31@h1$ lxc remote add h2 192.168.33.22

hirose31@h2$ lxc remote add h1 192.168.33.21
hirose31@h2$ lxc remote add h2 192.168.33.22


次にハマったのは、lxc moveするとこのようなエラーで失敗した点です。

hirose31@h1$ lxc move h1:c1 h2:
error: Error transferring container data: checkpoint failed:
(00.093894) Error (sockets.c:129): Diag module missing (-2)
(00.173958) Error (sockets.c:339): Sockets (family 16, proto 0) are not collected
(00.173977) Error (cr-dump.c:1303): Dump files (pid: 8476) failed with -1
(00.178203) Error (cr-dump.c:1600): Dumping FAILED.

エラーメッセージを見て、てっきりエラーの原因を表示するためのGo(LXDのlxcコマンドはGoで書かれています)のソケット関連のdiagnostic(診断)ライブラリが足りてないのかな?と思い、いろいろ調べたのですが、結局原因はGoは関係なく、netlink_diag.koというkernel moduleがなかったためでした。思い込みはよくないですね!

Ubuntu 16.04ではnetlink_diag.koは別パッケージに収録されているのでそれをインストールします。

sudo apt-get install linux-image-extra-$(uname -r)

これでlive migrationが成功しました!

ちなみにですけど、netlink_diag.koがないとstateful stop/start やstateful snapshotsも失敗します。


他に気をつける点は、ググるとひっかかる古い情報ではprofileを変更してたりしますが、デフォルトのdefault profileだけで動きました。むしろ、下手にいじると動かない場合がありました。

LXDの感想

システムコンテナとしてDockerを使い、CentOS 6とUbuntu 14.04を動かそうとしたときはいろいろハマった(gettyがCPU食いつぶすとかudevadm settleでbootが止まるとかとか)んですが、LXDでは images.linuxcontainers.org のイメージを使った限りではすんなりCentOS 6やUbuntu 16.04が動かせていまのところはだいぶ好印象です。

LXDはOpenStackとの連携もできるようですし、より軽量なKVMの代替としてよい選択肢になるんじゃないかと思います。

追記 2017-02-10

live migration元と先とでlxdのバージョンが違うと(例えば2.0.5と2.0.8)このようなエラーで失敗する。

move: error: Bad key: volatile.idmap.base

バージョンを揃えれば成功する。apt-get install lxd でコンテナは稼働したままバージョンを上げられた。

2003 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 05 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 12 |
2012 | 01 | 02 | 03 | 06 | 08 | 10 | 11 | 12 |
2013 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 10 |
2015 | 01 | 02 | 07 | 10 |
2016 | 01 | 05 | 10 | 12 |