今まではConohaを利用していました。
日本にLocationがあると、SSH越しの作業が非常に快適なのですが、回線が100Mbpsと細いのでBackupをどこかに転送する時に時間がかかります。

安いサーバを探していたところ、Contaboを見つけたので契約してみました。どれくらい安いかというとこのような感じです。端的に言うとかなり良いです。

価格をまとめてみました

Priceの円は実際に初期費用を請求された時のレートで算出してキリのの良いところで適当に調整。
セットアップ費用は年払いをすると0円です。月払いにすると4.99€かかります。今回契約したのはVPS L SSDプランの月額払いなので14.99+4.99=19.98€。
Paypal上で為替レート1 JPY = 0.0079 EUR、Paypalの支払いをRakutenカードにしていて実際に請求された額は2505円でした。

支払い手段は「PayPal」や「Skrill」を利用する事ができます。私はPayPalを利用しました。

このスペックでこの値段はかなり安いと思います。
契約したVPS-L-SSDはCPUとメモリだけで言えば、AWSのm5.2xlargeくらいのスペックでしょうか。Conohaで言うと26000円/月くらいかかるコースです。Diskが800GBもあるのでかなり太っ腹です。

利用できるOSは次の通りです。

支払い

チャージする形です。
PayPalを利用すれば自動で毎回支払う事ができます。

契約すると

モダンではないので、人の手が介在します。
ポチポチしたら直ぐに利用できるわけではありません。利用可能になるまで3日ほどかかります（と書かれていますが、実際は2時間くらいで使えるようになりました）

登録したらメールが来て、必要な情報が揃ってないから作業を進める事ができないよと言われました。

Dear Sir or Madam,

Thank you very much for your order and your payment.

During the order process, you have entered your contact data, such as your address, e-mail address and so on. Unfortunately, we were not able to verify your contact data. Perhaps you have made an error while entering it on our website. Therefore we ask you, to send us your contact data once again.

Step 1 of 2)

To do so, please reply to this e-mail and fill in the form below:

First name:
Last name:
Street:
Street number:
City:
ZIP code:
Country:
Telephone number:

Step 2 of 2)

False or fraudulent orders are commonplace on the Internet. We have to take measures to prevent such false or fraudulent orders. Our system has identified your order as a possible false order. We must now prove your order as a valid order, otherwise we cannot provide you with the services you bought. We need your help with this. Please send us a copy of your passport or national identity card or something similar which corresponds to the data you have provided to us. Alternatively, you can send us your telephone or electricity bill if it contains your address. The address must match the address you provided on our homepage. It is sufficient if you simply take a photo of the document. The only purpose of this is to prove your order as authentic. This is why it does not matter which of the mentioned documents you send us and it does not matter if you make a scan or take a photo. A scammer could not provide any of these documents, this means one document is already enough to prove that your order is authentic and valid.

Please note that we cannot start the setup of your ordered products until you send us a response to this e-mail.

Your cooperation and your efforts are highly appreciated - thank you very much!

If you have any questions or need help, please do not hesitate to contact us.

いやいや、登録フォームに全部書いてあるし、なんだったらPayPalで既に初期費用と最初の1ヶ月支払い済みですけどー？と思ったけど、その5分後に次のメールが来ました。

Dear xxxxxxxx

We have performed a further more detailed analysis of the situation and we would like to inform you that we do not require further details from you. Thus, no action from your end is required. We are sorry for the inconvenience.

We will now start the setup of your ordered VPS. Usually the setup will be finished within the next 24 hours. As soon as everything has been done from our side we will get back to you and provide you with your login details.

Your patience is highly appreciated for the time being.

We do wish you much success with our products.

さらにその30分後くらいにアカウント情報がメールで届きました。はやかった。

最初の設定

今時のサービスでは管理画面でポチポチして、鍵を登録して仮想マシンを起動しますが、そんなモダンではありません。登録時にメールで次の情報が届きます。

• Webコンソールの情報
  • Consoleのアドレス
  • UserName
  • Password
• VPSの情報
  • IP Address (v4 + v6)
  • VNCの情報
    • IP Address
    • Port
    • Password
    • User (root)
    • Password (VNCのパスワードとLinuxのrootパスワードは同じ)

パスワードが生で書かれているぜっ・・！
Webコンソールで出来ることは、再起動やSnapshotを取ることくらいしか出来ません。あと、DNSの逆引き設定が出来るくらいです。

VNCで接続してLinuxにログインできる事を確認。
sshdの設定で、鍵認証+パスワード認証をOFF、rootのssh禁止、listen portの変更を。ユーザーまわりはrootのパスワード変更、作業用ユーザーの追加とsudo設定あたりをささっとやってしまいます。

あと、TimeZoneがドイツになっているのでUTCに変更します。

実際のスペック情報

ドイツにあるので、通信遅延が大きいためSSHが快適ではありません。moshを使うことをオススメします。

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=51 time=249 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=2 ttl=51 time=247 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=3 ttl=51 time=244 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=51 time=244 ms
64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=51 time=243 ms

processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 79
model name      : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
stepping        : 1
microcode       : 0x1
cpu MHz         : 2199.996
cache size      : 16384 KB
physical id     : 0
siblings        : 8
core id         : 7
cpu cores       : 8
apicid          : 7
initial apicid  : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat umip md_clear arch_capabilities
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit
bogomips        : 4399.99
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

              total        used        free      shared  buff/cache   available
Mem:          30151         761       28974           3         415       29035
Swap:          2047           0        2047

個人的には、OSとデータの領域は分離してIOがさちった時にOS巻き込んで遅くなるのを防ぎたい派なのですが、これはまぁ仕方ないです。

Filesystem      Size  Used Avail Use% Mounted on
udev             15G     0   15G   0% /dev
tmpfs           3.0G  4.0M  3.0G   1% /run
/dev/sda2       786G   22G  725G   3% /
tmpfs            15G  4.0K   15G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            15G     0   15G   0% /sys/fs/cgroup
/dev/sda1       922M   60M  800M   7% /boot
tmpfs           3.0G     0  3.0G   0% /run/user/1000

Disk性能をfioで計測

fio -v 
fio-3.1

fio -filename=/root/work/test2g -direct=1 -rw=randrw -bs=4k -size=2G -numjobs=10 -iodepth=1 -runtime=20 -invalidate=1 -name=file1 -ioengine=libaio 

Run status group 0 (all jobs):
   READ: bw=5921KiB/s (6063kB/s), 566KiB/s-612KiB/s (579kB/s-627kB/s), io=116MiB (121MB), run=20001-20010msec
  WRITE: bw=5988KiB/s (6132kB/s), 589KiB/s-610KiB/s (604kB/s-625kB/s), io=117MiB (123MB), run=20001-20010msec

Disk stats (read/write):
  sda: ios=28449/29888, merge=0/13, ticks=10400/183500, in_queue=175836, util=99.11%

IOPSがかなり高い..!

実際に使ってみて

1ヶ月ほど利用していますが、ssh越しに作業をしなければかなり快適です。
開発サーバとして利用する場合や実験をする場合は、何かとsshで作業をする事が多いですが、運用するサーバとして使う場合は困った事がありませんでした。もちろん、DatabaseをCLIでクエリ流しまくる場合は(テキスト入力の遅延で)ストレスですが、そこはまぁトンネル掘ってGUIツールでアクセスすれば気にならないです。

大変満足しています。

ただし、複数台構成を考えているのであれば、オススメはしません。
今や多くのVPSでサポートされているLoad Balancerもなければprivate IPもありません。Object Storageのような便利なものもありません。AWSでいうところのセキュリティグループもないため、OS側できちんと守ってあげる必要があります。本当にClassicなVPSです。
安く仕上げたいがモダンなものは最低限欲しければ、VultrやDigital Oceanを使うのが良いですし、仕事で使うなら当然ながらAWSやGCPを使うのが良いです。

日本向けのWebサイトとして利用する場合は、前段にCDNを入れた方が良いです。
なお、契約してから1回だけメンテナンスがあり、サーバが再起動されました。メンテナンスがどの程度発生するのかはまだ分かっていません。

Dear xxxxxxxx,

With this e-mail, we would like to inform you that there is an immediate need for a short maintenance for your VPS L SSD (IP address xxx.xxx.xxx.xxx). Our technicians will do everything in their power to finish all tasks as quickly as possible. Unfortunately, there was no way to announce this maintenance earlier, which is why we apologize for any inconvenience.

The maintenance will take place on Wednesday, 5th February at 08:00 UTC+1.

The offtime is expected to last no longer than 45 minutes.

By the way, in the menu item “VPS control” of your Contabo customer control panel at https://my.contabo.com/vservers you can see the current status of maintenance with the help of the coloured warning triangles. Should there be displayed a green warning triangle, but you can see a black monitor under “Status” (Mouseover: Stopped), please click the button “Restart” once and wait a reasonable time. After the restart your VPS should be available soon.

Best regards,

Contabo Support Department

moshのssh-agent対応は公式では対応していません。ただし、#696にて対応パッチが作られています。レポジトリはこちら。
※port forward対応のパッチではありません。ssh-agent転送のパッチです。

前にMac<=>Amazon Linux1の間でこれをビルドして使っていたのですが、今回はWSL<=>Ubuntu18.04のためにビルドをしてみます。
protocol buffersはaptで入れます。（2020/03/09時点ではバージョンはv3.11.4でした。ubuntu18.04では3.0.0）

WSLはubuntu18.04を使っています。

sudo apt install -y autogen autoconf ncurses-dev libprotobuf-dev libprotoc-dev protobuf-compiler pkg-config

git clone https://github.com/rinne/mosh.git
cd mosh
./autogen.sh
./configure
make          # only build
make check    # with test
sudo make install

Server側もUbuntu18.04なので、上記と同じです。
あとは普通に実行。-Aオプションが使えるようになっています。

mosh --help | grep agent
-A      --forward-agent      enable ssh agent forwarding

mosh -A servername

もしServer側のバイナリを特定の場所にインストールしている場合は、mosh --server=/path/to/mosh-server servernameで。

Windows10でvscodeを起動し、Remote Development(WSL)で実行しています。
WSL(ubuntu18.04)ではanyenv->rbenvでrubyの環境を構築してあり、アプリケーションはsinatraを利用しています。

普段実行してるコマンドであるbundle exec rackup config.ruをdebug実行するにはbundle exec rdebug-ide --host 0.0.0.0 --port 1234 -- bundle exec rackup config.ruであるが、実行してもNo Such File ErrorかSyntaxErrorが発生します。前者はbundleをフルパスで指定していないから。後者はrbenvのbundleコマンドはruby実装ではなくshell scriptで実装されたラッパーだからである。
現在利用しているbundleコマンドの最終的なパスはrbenv which bundleで取得できるので、以下のように実行するとOKである。

bundle exec rdebug-ide --host 0.0.0.0 --port 1234 -- $(rbenv which bundle) exec rackup config.ru

設定手順一覧

1. VSCodeのRemote Development (WSL)を構築する

ここは本筋とは違うので省略。Remote DevelopmentがONの場合はフッタがこんな感じで表示されます。

2. VSCodeのExtensionをインストールする

• Ruby https://marketplace.visualstudio.com/items?itemName=rebornix.Ruby

Extensionをインストール後はVSCodeの再起動が必要。

3. VSCodeのデバッグ設定の追加

VSCodeのメニューから、デバッグ > 構成の追加 > Ruby > Listen for rdebug-ideを選択。

次のファイルが生成される。

{
    // IntelliSense を使用して利用可能な属性を学べます。
    // 既存の属性の説明をホバーして表示します。
    // 詳細情報は次を確認してください: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
    
        {
            "name": "Listen for rdebug-ide",
            "type": "Ruby",
            "request": "attach",
            "remoteHost": "127.0.0.1",
            "remotePort": "1234",
            "remoteWorkspaceRoot": "${workspaceRoot}"
        }
    ]
}

RemoteDevelopment先がWSLの場合は、remoteWorkspaceRootを書き換えなくてもOKでした。

4. Gemfileに必要なgemを追加

開発環境の時だけ。

group :development do
  gem "ruby-debug-ide"
  gem "debase"
end

bundle install

5. 実行

Terminalを立ち上げると、bashが起動するはずなので、次のコマンドを実行。

bundle exec rdebug-ide --host 0.0.0.0 --port 1234 -- $(rbenv which bundle) exec rackup config.ru

Fast Debugger (ruby-debug-ide 0.7.0, debase 0.2.4.1, file filtering is supported) listens on 0.0.0.0:1234

VSCodeのメニューから、デバッグ > デバッグの開始を実行。次のようにアプリが実行されたログが出れば成功。

[2020-03-06 14:32:50] INFO  WEBrick 1.4.2
[2020-03-06 14:32:50] INFO  ruby 2.6.3 (2019-04-16) [x86_64-linux]
[2020-03-06 14:32:50] INFO  WEBrick::HTTPServer#start: pid=31802 port=9292

後は、VSCode上でブレークポイントを設定するなどして、いつものようにデバッグできる。

参考

• https://qiita.com/naoto_koyama/items/313e45a0f26e1e641728
• https://qiita.com/saboyutaka/items/fc147478db58eeeaa742

XREAのサーバでMovableType4.01を動かしていたのですが、すごい放置をしていたらサーバの更新でPerlのバージョンが上がり、動かなくなってしました。このMovableTypeをアップグレードして、次の対応します。

• テンプレートを変更し、モバイル対応する
• HTTPS対応
• Canonical URLは変わらないようにする (HTTP -> HTTPSはするけど)

無理矢理動くようにする

• definedの部分のコードを書き換える
• mt-config.cgiにSQLSetNames 1を追加する(文字化けするので)

これで動くようにはなります。
しかしMT4のテンプレートでレスポンシブ対応しているものを見つけるのは大変。元々使っていたテンプレートのサイトも閉鎖されていました。

再現環境を手元に作る / XREAの情報

今動いているXREAのサーバでは次のものが動いています。

• Apache 2.4
• Perl 5.16.3
• MySQL 5.7.27

Perlのdefined関連がおかしいので、Perl5.10よりも前のもので動いていたのだと思います。XreaはSSHできるので、他にも情報を集めます。

[client]
default-character-set = utf8
[mysqld]
character-set-server = utf8
[mysqldump]
default-character-set = utf8
[mysql]
default-character-set = utf8

mysql> show variables like '%chara%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.11 sec)

環境をUbuntu18.04で作る

もっと古いubuntuを使った方が良いのかもしれませんが。

apt update
apt install build-essential mysql-server libmysqlclient-dev perlbrew apache2

perlbrew install --notest perl-5.8.6   # 元の環境
perlbrew install --notest perl-5.16.3  # 今の環境
perlbrew use perl-5.8.6

cpan 
> notest install Digest::SHA Devel::CheckLib
> notest install CGI Image::Size File::Spec CGI::Cookie DBI DBD::mysql HTML::Entities LWP::UserAgent XML::Atom MIME::Base64 IO::Compress:Gzip IO::Uncompress:Gunzip Crypt::DSA


perlbrew switch perl-5.16.3

cpan
notest install CGI Image::Size File::Spec CGI::Cookie DBI DBD::mysql HTML::Entities LWP::UserAgent XML::Atom MIME::Base64 IO::Compress:Gzip IO::Uncompress:Gunzip Crypt::DSA

ローカルで適当に動けばいいやレベルの設定。

<VirtualHost *:80>
        ServerName mt.orz.at
        DirectoryIndex index.html

        ServerAdmin webmaster@localhost
        LogLevel info

        ErrorLog ${APACHE_LOG_DIR}/error_orz.log
        CustomLog ${APACHE_LOG_DIR}/access_orz.log combined

        AddHandler cgi-script .cgi .pl
        DocumentRoot "/data/mt.orz.at/"
        <Directory "/data/mt.orz.at/">
                AllowOverride All
                Options +ExecCGI
                Require all granted
        </Directory>
</VirtualHost>

/etc/hostsに127.0.0.1 mt.orz.atを追加します。良くない方法だけど、VMの閉じた環境だし手っ取り早く動かしたいので。

XREAのコンソールからMySQLのDumpを取りローカルに持ってきます。

create database mydb default character set utf8;
CREATE USER 'myuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'mypassword';
GRANT ALL PRIVILEGES ON mydb.* TO 'myuser'@'localhost';

XREAサーバにあるファイル群をTARで固めてローカルに持ってきます。
mt.cgiのパスをperlbrewのパスに変更します。

これでローカルで動くようになりました。

ひとまずここまで。
MT4からMT7にはアップグレードできないため、次はこれを新しい環境にMT5を経由してMT7まであげます。
その後、それをXREAに持って行くか、XREA上でアップグレード作業をするかのどちらかをします。

リゲッタ直営店が自由が丘にあり、そこに靴を買いに行きました。今回は、ちょっとヒールがあるブーツで履きやすいものを探してました。個人的に好きなデザインが多く、気になっていたブランドです。
私の足は左24cm, 右24.3cm、幅が3Eくらいで甲がちょっと高い感じ。このサイズだとレディース、メンズ共になかなか合うサイズが無いのです。

リゲッタ：https://www.regeta.co.jp/brand/index.html

天気が悪かったせいかお客さんがあまり多くない時間に行ったようで、たくさんの靴を試すことが出来ました。このリゲッタの靴、土踏まずが気持ちよく、今まで履いたどの靴よりも履き心地が良いです。しかも、いろんな靴で全部履き心地が微妙に違うのが分かって面白い。

全部履き心地が違うので、全部欲しくなる。

またヒールがある靴であっても、ヒール感はなくフラットな履き心地です。走れます。試しに9cmというパンプスを履かせてもらったのですが、体感は7cmくらいとの事で、しかも普通に走れるくらいの履き心地でした。

実際に履いてみるのが一番。リゲッタの場合、私はメンズよりもレディースの方が足がぴったり合うらしい。
店員さんの接客もとても気持ちよく、こちらの悩みや疑問にも答えてくれて、今度から靴はリゲッタで買おうと思います。

実際購入したのはこちらのCJAL-4102。この色の在庫が無かったので、大阪から送ってもらいました。

さらに、店舗には色が無かったのでネットでCJAW-4305も購入しました。こちらは履き心地の特徴が一番感じられる靴でした。

本当に素晴らしいブランドだと思います。

体調不良が治ったと言ったな。アレは嘘だ。
というのは嘘で、体調不良自体は回復しているのですが、それとは別に腸閉塞で8日間入院しました。

12/17に腹痛がとても激しく朝6時前に目が覚めました。おへその周りの断続的な痛み、刺すような痛みと雑巾を絞っているようなぎゅーっとなる痛みがありました。少しすれば治るかなと思ったのですが、9時過ぎても全然良くならなく、軽い吐き気も出てきました。

近所の病院に行ったらかなり待たされて、結果的に大学病院の紹介状をもらいました。そこは通院している大学病院だったので、そもそも最初から大学病院に行けば良かったという話でもあります。実際、先生になんで最初からこっち来ないのと言われました。

調べてみると、腸閉塞と胃腸炎のダブルパンチで緊急入院になりました。回腸がものすごく膨張していたみたいです。点滴で痛み止めを打ってもらい、1時間くらいしたら痛みは無くなりました。私の既往歴から、腸閉塞に定期的にかかっていること、胃腸炎の頻度がかなり高い(今年だけで4回以上やらかしている)事から、クローン病の疑いがあるとのことで検査をする事になりました。

https://www.min-iren.gr.jp/?p=4165
このページにある検査を全部やりました。ほぼ毎日検査。

絶飲食がなかなかつらい。お水も飲めません。全部で点滴は7.5リットル打ちました。特にやる事も無く、ずっと本を読んだりゲームをしたりしてました。腸閉塞が治った後はずっと検査入院のような感じだったので、外出1回、外泊(大量の荷物受け取り)を1回しました。
結果的にクローン病の疑いはありませんでした。

入院すると、いろんな役割の人が居て、外来をやっていない時間に先生は何をやっているのかが分かって新しい気づきがあり面白かったです。

そうそう、入院中に宝くじをネットで買ったのですが、10万円当たりました🙌

入院費も10万円くらいでした😭

その後も体調を崩しまくりでした。
毎日体調を崩し、1日の中でも数時間体調不良により吐き気や目眩が止まりませんでした。食事に行っても、ついさっきまでは元気だったのに注文後急に体調を崩して、一切食事が取れなくなる事もありました。
座っていても目がぐるぐるまわる感じで、横になって目を閉じないと吐き気を催してしまう感じで、送別会に行っても途中で寝込んでしまったり。

そこに追い打ちをかけるように、胃腸炎や扁桃炎になる事も多く、QoLはかなり下がり、いくつか病院にも行きました。11月の症状のメモを見るだけでも、胃腸炎、扁桃炎、高熱、倦怠感、下痢、吐き気、冷や汗、耳が遠くなる、目眩 などなど。

自律神経失調症の症状が全部出ていた感じなのですが、ある人に「それ更年期障害と似たような症状だね」と言われ、それがヒントになりました。飲んでいたサプリを全部やめたら12月の上旬には症状が収まり始めました。調べてみると健康被害もそれなりに出ているらしく、完全にコレのせいです。

再現テストは怖くてしていませんが、ひとまず2019年後半から続いていた体調不良の原因が分かりました。

2019年5月下旬から大きく健康を害しまして、今も完治はしていません。何が起きてどう対処したのか、今後再発した時の自分のためのメモです。

発症まとめ

• 熱中症を4回ほど起こした。うち1回は救急車。その熱中症と胃腸炎を併発した。
• 発症した症状
  • 不眠症
  • 食事をすると体調が崩れる
  • 微熱が続き、時々低体温になる
  • 便秘と下痢を繰り返す
  • お腹の気持ち悪さ
  • お腹にガスがたまり、なかなか下の方に降りてこない
  • 呼吸が浅くなる（速くなる）
  • 横になって目を瞑らないと駄目になる
  • 実際に嘔吐はしていないが、吐き気が非常に出る
  • IBS+PD
  • 胆石症の症状

時系列

5/26

• 渋谷にて熱中症。救急車で運ばれた。
  • 急に気持ち悪くなったというよりも、なんか違和感を感じて、呼吸が浅くなり立ってられなくなった。
  • しばらく様子を見て水分補給をしたが改善せず。
  • 吐き気や手足の痺れが出た。
  • Taxiで家まで帰ろうとしたがTaxiを捕まえるために大きな道まで出られず、救急車を呼んだ。

6/4

会社から知人の家まで移動後、熱中症に。

• 徒歩20分くらいを移動。
• 移動後、水を飲んだらお腹に違和感が出てきた。
• だんだん気持ち悪くなり、熱中症のような感じになった。呼吸が浅くなり、気持ち悪くなった。
• 吐き気と手足の痺れに加えて、顔の痺れも出た。顔は特に左側。
• 頭の左後ろがぼあーとする感じがあった。
• 横になっても目眩がずっと続く。
• 動くと非常に気持ち悪い。
• 目を開けてると気持ち悪く、目を瞑ると少し楽なった。
• 深呼吸をすると気持ち悪くなる。
• Taxiで家に帰る。病院に連絡はした。
• 帰宅しても気持ち悪さがとれず。

6/5

• 4時頃起床
  • 気持ち悪さが続いていた。
  • 食事が全然とれず、ウィダーインゼリーなどで補給。
  • 震えるほど寒かった。
• 10時頃
  • 気持ち悪さが続く。
  • トイレで排尿と排便(Not下痢)は出た。
• 胃が荒れている感じがあった。
• 経口補水液で水分補給。
• 手に力が入らない。
• 胃の下（へその下あたり）がむあーとする
• 12時 熱は36.5～37.1
• 13時
  • 体温は37.5
  • 下痢気味の便が出る
  • 気持ち悪さ、吐き気に波がある
  • 背中の痛みが出る
  • 横になると目眩が時々発生する
  • 汗が時々噴き出るように出る
• 病院へ
• 帰宅しても気持ち悪さが引き続き発生
• 食事はおにぎりを食べる
• 22時 まで寝まくる
  • 胃が荒れている感じ
  • 気持ち悪さが無くなる
  • 頭が重い
  • 背中の痛みは続く

6/6

• 起き上がると気持ち悪い
• 12時 体温 37.1
• 14時 体温 37.1 下痢
  • 気持ち悪さ。特に立つと気持ち悪い。胃がムカムカする。
• 16時 体温 37.1
  • 締め付けられる感じの頭痛が発生する。M字のてっぺんのところ2カ所が非常に痛い
• 22時 体温 37.1
  • 目を開けていると気持ち悪い

6/7

• 6:30 起床 体温は平熱で36.4 背中の痛みが軽減
• 胃に何か食べ物が入ってくるとむあーとしたのが続く
• 体を動かすと座っていても立ちくらみのような目眩と気持ち悪さが出る
• みぞおちが痛い
• 無心になり目を閉じると楽になる

夜は少し調子が良かった

6/8

• 体温は平熱に戻り、 36.4
• タール状の便
• 11時頃 気持ち悪さが出る
• 13時頃 下痢。体温は37.1。
• 夜まで微熱が続く

6/9

• 微熱が続く。
• 下痢
• 何か食べると気持ち悪くなるので、ほぼ水分補給のみ

6/10

• 微熱が続く 体温 37.0
• この時点で体重が2.5kgほど減少。
• 健康診断があったのでなんとか外出して受けてくる。

6/14

• 体調が回復傾向にありAWSのイベントに参加していた
• 熱中症っぽくなり医務室で2時間ほど横になる
• なんとか幕張から帰宅して家で横になる

6/18

• 背中が痛くて目が覚める。胆石症のような症状。

6/20

• 微熱が出る。お腹が気持ち悪い。便秘

6/21

• 背中が痛く、微熱が続く。
• お腹が気持ち悪い。この日は下痢。

6/22

• 背中の痛みで25時頃目が覚めてしまう
• お腹が気持ち悪い。排便有り。
• 微熱が続く。
• お店の予約があったので渋谷まで移動したが、ふらつきや脱水症状が出てしまった。呼吸が浅くなり気持ち悪くなり、帰宅
• 体温は35.6
• 腕とふくらはぎが重い
• 19:30に体温を測ると37.4

6/23

• 体が非常にだるく、不眠が続く。夜中の3時頃に目が覚めてしまう。
• おへその下の不快が続く。
• 食事をするとおへその上あたりに違和感を感じ、おへその下にぬるま湯が入っている感じの不快感が出る。
• 吐き気が凄い

6/24

• 表参道に移動したが、気分が悪くなる。
• 吐き気、呼吸が浅くなる。
• 体に力が入らなくなってだるくなる。目を瞑って横になると少し楽になる。
• 水分補給をするとお腹が不快な感じになる
• Taxiで大崎の病院へ

過敏性腸症候群(IBS)+パニック症候群(PD)と言われる。

6/25

• 不眠症になり1時、4時に目が覚める。
• お腹の不快はお風呂で体を温めることで解消
• 便秘
• 夜になると微熱と頭痛が出る

6/26

• 排便有り
• お腹が気持ち悪い
• 移動で気持ち悪くなる
• 帰宅後気持ち悪くなる
• 夜 下痢になる

6/27

• 体がだるいが胃は治った感じがする
• 下痢が続く
• 食事がつらいのでコンソメスープ＋おにぎり

7/6

• みぞおちが痛すぎて眠れなくなる

突然いろいろなサービスの名前解決が出来なくなってPODがエラーを吐き始めました。GKEのConsoleで見ていたら、しばらく経つとエラーは無くなりましたがkube-dnsだけCrashLoopBackOffでステータスがDoes not have minimum availabilityと表示されていました。

調べたこと

kube-dnsはnamespaceがkube-systemのDeployment,Replica=2として動くように定義されています。

# kubectl -n kube-system get pod | grep kube-system

4/4       Running            0          45m       10.4.0.132   gke-pn-cluster-2-pn-pool-1-efba661f-pz54   <none>
kube-dns-76dbb796c5-9gljt                             3/4       CrashLoopBackOff   13         45m       10.4.0.134   gke-pn-cluster-2-pn-pool-1-efba661f-pz54   <none>
kube-dns-autoscaler-67c97c87fb-rj4fq                  1/1       Running            0          45m       10.4.0.135   gke-pn-cluster-2-pn-pool-1-efba661f-pz54   <none>

このpodの定義を見ると、4つのcontainerが含まれており、kubedns, dnsmasq, sidecar, prometheus-to-sdがありました。

# kubectl -n kube-system describe pod kube-dns-76dbb796c5-9gljt

Name:               kube-dns-76dbb796c5-9gljt
Namespace:          kube-system
Priority:           2000000000
PriorityClassName:  system-cluster-critical
Node:               gke-pn-cluster-2-pn-pool-1-efba661f-pz54/10.146.0.2
Start Time:         Sun, 05 May 2019 14:46:19 +0900
Labels:             k8s-app=kube-dns
                    pod-template-hash=3286635271
Annotations:        scheduler.alpha.kubernetes.io/critical-pod=
                    seccomp.security.alpha.kubernetes.io/pod=docker/default
Status:             Running
IP:                 10.4.0.134
Controlled By:      ReplicaSet/kube-dns-76dbb796c5
Containers:
  kubedns:
    Container ID:  docker://2e341ab157aee24b63d95eefb4da434c79306229055d135abf6b730708589d68
    Image:         k8s.gcr.io/k8s-dns-kube-dns-amd64:1.14.13
    Image ID:      docker-pullable://k8s.gcr.io/k8s-dns-kube-dns-amd64@sha256:618a82fa66cf0c75e4753369a6999032372be7308866fc9afb381789b1e5ad52
    Ports:         10053/UDP, 10053/TCP, 10055/TCP
    Host Ports:    0/UDP, 0/TCP, 0/TCP
    Args:
      --domain=cluster.local.
      --dns-port=10053
      --config-dir=/kube-dns-config
      --v=2
    State:          Running
      Started:      Sun, 05 May 2019 14:46:42 +0900
    Ready:          True
    Restart Count:  0
    Limits:
      memory:  170Mi
    Requests:
      cpu:      100m
      memory:   70Mi
    Liveness:   http-get http://:10054/healthcheck/kubedns delay=60s timeout=5s period=10s #success=1 #failure=5
    Readiness:  http-get http://:8081/readiness delay=3s timeout=5s period=10s #success=1 #failure=3
    Environment:
      PROMETHEUS_PORT:  10055
    Mounts:
      /kube-dns-config from kube-dns-config (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-dns-token-jdksn (ro)
  dnsmasq:
    Container ID:  docker://5cc16055a401b91bd15ba6507c9f2b7b4e4b20647496746d978cb211e1a0555d
    Image:         k8s.gcr.io/k8s-dns-dnsmasq-nanny-amd64:1.14.13
    Image ID:      docker-pullable://k8s.gcr.io/k8s-dns-dnsmasq-nanny-amd64@sha256:45df3e8e0c551bd0c79cdba48ae6677f817971dcbd1eeed7fd1f9a35118410e4
    Ports:         53/UDP, 53/TCP
    Host Ports:    0/UDP, 0/TCP
    Args:
      -v=2
      -logtostderr
      -configDir=/etc/k8s/dns/dnsmasq-nanny
      -restartDnsmasq=true
      --
      -k
      --cache-size=1000
      --no-negcache
      --log-facility=-
      --server=/cluster.local/127.0.0.1#10053
      --server=/in-addr.arpa/127.0.0.1#10053
      --server=/ip6.arpa/127.0.0.1#10053
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    255
      Started:      Sun, 05 May 2019 15:28:15 +0900
      Finished:     Sun, 05 May 2019 15:28:16 +0900
    Ready:          False
    Restart Count:  13
    Requests:
      cpu:        150m
      memory:     20Mi
    Liveness:     http-get http://:10054/healthcheck/dnsmasq delay=60s timeout=5s period=10s #success=1 #failure=5
    Environment:  <none>
    Mounts:
      /etc/k8s/dns/dnsmasq-nanny from kube-dns-config (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-dns-token-jdksn (ro)
  sidecar:
    Container ID:  docker://f8c87600c704dd709d27c518d0b3ce20d944608be16f1436442970454715977a
    Image:         k8s.gcr.io/k8s-dns-sidecar-amd64:1.14.13
    Image ID:      docker-pullable://k8s.gcr.io/k8s-dns-sidecar-amd64@sha256:cedc8fe2098dffc26d17f64061296b7aa54258a31513b6c52df271a98bb522b3
    Port:          10054/TCP
    Host Port:     0/TCP
    Args:
      --v=2
      --logtostderr
      --probe=kubedns,127.0.0.1:10053,kubernetes.default.svc.cluster.local,5,SRV
      --probe=dnsmasq,127.0.0.1:53,kubernetes.default.svc.cluster.local,5,SRV
    State:          Running
      Started:      Sun, 05 May 2019 14:46:50 +0900
    Ready:          True
    Restart Count:  0
    Requests:
      cpu:        10m
      memory:     20Mi
    Liveness:     http-get http://:10054/metrics delay=60s timeout=5s period=10s #success=1 #failure=5
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-dns-token-jdksn (ro)
  prometheus-to-sd:
    Container ID:  docker://82d84415443253693be30368ed14555ff24ba21844ae607abf990c369008f70e
    Image:         k8s.gcr.io/prometheus-to-sd:v0.4.2
    Image ID:      docker-pullable://gcr.io/google-containers/prometheus-to-sd@sha256:aca8ef83a7fae83f1f8583e978dd4d1ff655b9f2ca0a76bda5edce6d8965bdf2
    Port:          <none>
    Host Port:     <none>
    Command:
      /monitor
      --source=kubedns:http://localhost:10054?whitelisted=probe_kubedns_latency_ms,probe_kubedns_errors,dnsmasq_misses,dnsmasq_hits
      --stackdriver-prefix=container.googleapis.com/internal/addons
      --api-override=https://monitoring.googleapis.com/
      --pod-id=$(POD_NAME)
      --namespace-id=$(POD_NAMESPACE)
      --v=2
    State:          Running
      Started:      Sun, 05 May 2019 14:46:51 +0900
    Ready:          True
    Restart Count:  0
    Environment:
      POD_NAME:       kube-dns-76dbb796c5-9gljt (v1:metadata.name)
      POD_NAMESPACE:  kube-system (v1:metadata.namespace)
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-dns-token-jdksn (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  kube-dns-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      kube-dns
    Optional:  true
  kube-dns-token-jdksn:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  kube-dns-token-jdksn
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     CriticalAddonsOnly
                 node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                 Age                 From                                               Message
  ----     ------                 ----                ----                                               -------
  Normal   Scheduled              46m                 default-scheduler                                  Successfully assigned kube-system/kube-dns-76dbb796c5-9gljt to gke-pn-cluster-2-pn-pool-1-efba661f-pz54
  Normal   SuccessfulMountVolume  46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  MountVolume.SetUp succeeded for volume "kube-dns-config"
  Normal   SuccessfulMountVolume  46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  MountVolume.SetUp succeeded for volume "kube-dns-token-jdksn"
  Normal   Pulling                46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  pulling image "k8s.gcr.io/k8s-dns-kube-dns-amd64:1.14.13"
  Normal   Pulled                 46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Successfully pulled image "k8s.gcr.io/k8s-dns-kube-dns-amd64:1.14.13"
  Normal   Created                46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Created container
  Normal   Started                46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Started container
  Normal   Pulling                46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  pulling image "k8s.gcr.io/k8s-dns-dnsmasq-nanny-amd64:1.14.13"
  Normal   Pulled                 46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Successfully pulled image "k8s.gcr.io/k8s-dns-dnsmasq-nanny-amd64:1.14.13"
  Normal   Pulling                46m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  pulling image "k8s.gcr.io/k8s-dns-sidecar-amd64:1.14.13"
  Normal   Created                45m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Created container
  Normal   Pulled                 45m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Successfully pulled image "k8s.gcr.io/k8s-dns-sidecar-amd64:1.14.13"
  Normal   Pulling                45m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  pulling image "k8s.gcr.io/prometheus-to-sd:v0.4.2"
  Normal   Started                45m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Started container
  Normal   Created                45m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Created container
  Normal   Started                45m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Started container
  Normal   Pulled                 45m                 kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Successfully pulled image "k8s.gcr.io/prometheus-to-sd:v0.4.2"
  Normal   Created                45m (x2 over 46m)   kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Created container
  Normal   Started                45m (x2 over 46m)   kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Started container
  Normal   Pulled                 45m (x2 over 45m)   kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Container image "k8s.gcr.io/k8s-dns-dnsmasq-nanny-amd64:1.14.13" already present on machine
  Warning  BackOff                1m (x211 over 45m)  kubelet, gke-pn-cluster-2-pn-pool-1-efba661f-pz54  Back-off restarting failed container

Logを見ますが、普通に起動できている（ように見えてました）。

# kubectl -n kube-system logs kube-dns-76dbb796c5-9gljt -c kubedns

I0505 05:46:42.318712       1 dns.go:48] version: 1.14.13
I0505 05:46:42.322157       1 server.go:69] Using configuration read from directory: /kube-dns-config with period 10s
I0505 05:46:42.322453       1 server.go:121] FLAG: --alsologtostderr="false"
I0505 05:46:42.322508       1 server.go:121] FLAG: --config-dir="/kube-dns-config"
I0505 05:46:42.322517       1 server.go:121] FLAG: --config-map=""
I0505 05:46:42.322636       1 server.go:121] FLAG: --config-map-namespace="kube-system"
I0505 05:46:42.322718       1 server.go:121] FLAG: --config-period="10s"
I0505 05:46:42.322739       1 server.go:121] FLAG: --dns-bind-address="0.0.0.0"
I0505 05:46:42.322746       1 server.go:121] FLAG: --dns-port="10053"
I0505 05:46:42.322756       1 server.go:121] FLAG: --domain="cluster.local."
I0505 05:46:42.322856       1 server.go:121] FLAG: --federations=""
I0505 05:46:42.322878       1 server.go:121] FLAG: --healthz-port="8081"
I0505 05:46:42.322886       1 server.go:121] FLAG: --initial-sync-timeout="1m0s"
I0505 05:46:42.322895       1 server.go:121] FLAG: --kube-master-url=""
I0505 05:46:42.322983       1 server.go:121] FLAG: --kubecfg-file=""
I0505 05:46:42.323003       1 server.go:121] FLAG: --log-backtrace-at=":0"
I0505 05:46:42.323016       1 server.go:121] FLAG: --log-dir=""
I0505 05:46:42.323099       1 server.go:121] FLAG: --log-flush-frequency="5s"
I0505 05:46:42.323117       1 server.go:121] FLAG: --logtostderr="true"
I0505 05:46:42.323123       1 server.go:121] FLAG: --nameservers=""
I0505 05:46:42.323129       1 server.go:121] FLAG: --stderrthreshold="2"
I0505 05:46:42.323137       1 server.go:121] FLAG: --v="2"
I0505 05:46:42.323144       1 server.go:121] FLAG: --version="false"
I0505 05:46:42.323253       1 server.go:121] FLAG: --vmodule=""
I0505 05:46:42.323511       1 server.go:169] Starting SkyDNS server (0.0.0.0:10053)
I0505 05:46:42.331087       1 server.go:179] Skydns metrics enabled (/metrics:10055)
I0505 05:46:42.331168       1 dns.go:188] Starting endpointsController
I0505 05:46:42.331375       1 dns.go:191] Starting serviceController
I0505 05:46:42.331754       1 dns.go:184] Configuration updated: {TypeMeta:{Kind: APIVersion:} Federations:map[] StubDomains:map[] UpstreamNameservers:[]}
I0505 05:46:42.335926       1 logs.go:41] skydns: ready for queries on cluster.local. for tcp://0.0.0.0:10053 [rcache 0]
I0505 05:46:42.337525       1 logs.go:41] skydns: ready for queries on cluster.local. for udp://0.0.0.0:10053 [rcache 0]
I0505 05:46:42.835211       1 dns.go:222] Initialized services and endpoints from apiserver
I0505 05:46:42.835268       1 server.go:137] Setting up Healthz Handler (/readiness)
I0505 05:46:42.835298       1 server.go:142] Setting up cache handler (/cache)
I0505 05:46:42.835317       1 server.go:128] Status HTTP port 8081

Containerに入って、色々と確認してみます。
Livenessを手動で確認するという事をしてみます。curlがインストールされていないImageだったのでwgetを使っています。すると、dnsmasqのエラーが出てきました。

# kubectl exec -n kube-system -c kubedns -it kube-dns-76dbb796c5-9gljt sh

wget -O - http://localhost:10054/healthcheck/dnsmasq
Connecting to localhost:10054 (127.0.0.1:10054)
wget: server returned error: HTTP/1.1 503 Service Unavailable

dnsmasqにはLoginできないのでこっちがこけているっぽい。

kubectl exec -n kube-system -c dnsmasq -it kube-dns-76dbb796c5-9gljt sh

# kubectl -n kube-system logs kube-dns-76dbb796c5-9gljt -c dnsmasq

I0505 06:38:30.432185       1 main.go:74] opts: {{/usr/sbin/dnsmasq [-k --cache-size=1000 --no-negcache --log-facility=- --server=/cluster.local/127.0.0.1#10053 --server=/in-addr.arpa/127.0.0.1#10053 --server=/ip6.arpa/127.0.0.1#10053] true} /etc/k8s/dns/dnsmasq-nanny 10000000000}
I0505 06:38:30.432498       1 nanny.go:94] Starting dnsmasq [-k --cache-size=1000 --no-negcache --log-facility=- --server=/cluster.local/127.0.0.1#10053 --server=/in-addr.arpa/127.0.0.1#10053 --server=/ip6.arpa/127.0.0.1#10053]
I0505 06:38:30.992206       1 nanny.go:119]
W0505 06:38:30.992278       1 nanny.go:120] Got EOF from stdout
I0505 06:38:30.992242       1 nanny.go:116]
I0505 06:38:30.992337       1 nanny.go:116] dnsmasq: failed to create inotify: No file descriptors available
I0505 06:38:30.992385       1 nanny.go:123]
E0505 06:38:30.992407       1 nanny.go:124] Error reading from stderr: read |0: file already closed
F0505 06:38:30.992583       1 nanny.go:190] dnsmasq exited: exit status 5

dnsmasq: failed to create inotify: No file descriptors available とても怪しい。

# cat /proc/sys/fs/inotify/max_user_instances
128
# cat /proc/sys/fs/inotify/max_user_watches 
8192

nodeが2つ(GCEのVMが2つ)あって、VMのログなどを見ると1つのVMで以下のログを発見。

sudo journalctl -f
Failed to get journal fd: Too many open files

YAMLの定義を抜き出してきて、直接VM上で起動してみると起動できるVMとできないVMがあり、できないVMではjournallogに上記のログが出ていました。

docker run -it --rm k8s.gcr.io/k8s-dns-dnsmasq-nanny-amd64:1.14.13 \
    -v=2 \
    -logtostderr \
    -configDir=/etc/k8s/dns/dnsmasq-nanny \
    -restartDnsmasq=true \
    -- \ 
    -k \ 
    --cache-size=1000 \
    --no-negcache \
    --log-facility=- \ 
    --server=/cluster.local/127.0.0.1#10053 \
    --server=/in-addr.arpa/127.0.0.1#10053 \
    --server=/ip6.arpa/127.0.0.1#10053 \

対策

NodePoolを作ってそっちに全部移動させるか、NodePoolのNode数を増やしてdrainさせるか等を考えました。今回はVMで消費しているFDを見て、怪しいプロセスを消したり再起動したりする事にしました。
もう使っていないPODを消したり、ResourceLeakしてそうなPodを再起動したり。

これを行ったら、なんとか復旧しました。

その他メモ

GKEでNodePoolを作るときにubuntuではなくCOSにしていましたが、lsofが使えませんでした。toolkitを使ってapt-get update && apt-get install lsofで使えるようになりました。

ref: https://cloud.google.com/container-optimized-os/docs/how-to/toolbox

参考

• https://github.com/kubernetes/kops/issues/2709
• https://github.com/kubernetes/kubernetes/issues/32526
• https://cloud.google.com/container-optimized-os/docs/how-to/toolbox

とあるサーバのNTPDの同期ができていなかったので調べたメモ。

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 169.254.169.123 .INIT.          16 u    - 1024    0    0.000    0.000   0.000

*が付いていないしreachも0なので同期できていない。

ntpdcで該当NTPサーバとの通信の状況を見てみる。サーバはAWSのTimeServerを利用しています。

# ntpdc -c 'showpeer 169.254.169.123'
remote 169.254.169.123, local 10.0.103.31
hmode client, pmode unspec, stratum 16, precision -22
leap 11, refid [73.78.73.84], rootdistance 0.00000, rootdispersion 0.00000
ppoll 10, hpoll 10, keyid 0, version 4, association 35382
reach 000, unreach 213, flash 0x1600, boffset 0.00000, ttl/mode 0
timer 0s, flags config, bclient, prefer
reference time:      00000000.00000000  Mon, Jan  1 1900  0:00:00.000
originate timestamp: e0754e65.00000000  Thu, May  2 2019 11:09:25.000
receive timestamp:   00000000.00000000  Mon, Jan  1 1900  0:00:00.000
transmit timestamp:  00000000.00000000  Mon, Jan  1 1900  0:00:00.000
filter delay:  0.00000  0.00000  0.00000  0.00000
               0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
               0.000000 0.000000 0.000000 0.000000
filter order:  0        1        2        3
               4        5        6        7
offset 0.000000, delay 0.00000, error bound 3.99217, filter error 0.00000

unreach 213, flash 0x1600 unreachのカウンタが増えていますし、flashの値にも何か記録されています。

ntp.hの定義を見ると、次のようになっています。0x1600ということはTEST10|TEST11|TEST13ということ？

#define TEST10          0x0200  /* peer bad synch or stratum */
#define TEST11          0x0400  /* peer distance exceeded */
#define TEST12          0x0800  /* peer synchronization loop */
#define TEST13          0x1000  /* peer unreacable */

NICが2枚刺さっているサーバらしい

eth0が10.0.103.31, eth1が10.0.100.111でeth1がDEFROUTE=1。
ntpdがlistenしているのはeth0のみ。

netstat -tulpn | grep :123
udp        0      0 10.0.103.31:123             0.0.0.0:*                               2995/ntpd
udp        0      0 127.0.0.1:123               0.0.0.0:*                               2995/ntpd
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               2995/ntpd

設定ファイルを見ると、listenはeth0のみ。なのでここにinterface listen eth1を追加してntpdを再起動しました。

interface listen eth0
interface ignore ipv6

結果、同期されるようになりました。

疑問点

NICは同じネットワークアドレスを持っている。そして、ip routeやrouteを見ると、eth1のFlags=Gが2つあるのがすごい怪しい。

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.100.1      0.0.0.0         UG    0      0        0 eth1
0.0.0.0         10.0.100.1      0.0.0.0         UG    10001  0        0 eth1
10.0.100.0      0.0.0.0         255.255.252.0   U     0      0        0 eth0
10.0.100.0      0.0.0.0         255.255.252.0   U     0      0        0 eth1
169.254.169.254 0.0.0.0         255.255.255.255 UH    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

どういう設定をしたサーバなのか調査する時間がないので、ここまで。

参考

• http://d.hatena.ne.jp/iwasakims/20120702/1341193189