Windows10とUbuntuを入れたPCでWindowsを起動するとなぜか毎回UTCになり9時間マイナスになる。その時刻ずれおかげでAWS CLIが正しく起動しないなどの副作用もあるので何とかしたいと思っていた。
既定の地域がアメリカになっているという情報があったので日本にしたのだが、それでも時間がずれる。調べてみるとLinuxとマルチブートしているとLinux起動時にずれるらしいという情報を得た。
一応原因は分かったのでマルチブートの時はWindows10は使わない!という回避策で!
Windows10とUbuntuを入れたPCでWindowsを起動するとなぜか毎回UTCになり9時間マイナスになる。その時刻ずれおかげでAWS CLIが正しく起動しないなどの副作用もあるので何とかしたいと思っていた。
既定の地域がアメリカになっているという情報があったので日本にしたのだが、それでも時間がずれる。調べてみるとLinuxとマルチブートしているとLinux起動時にずれるらしいという情報を得た。
一応原因は分かったのでマルチブートの時はWindows10は使わない!という回避策で!
バージョン飛びすぎていろいろアプリケーションでエラーがでていた。
主要なミドルウェアはもちろん問題ないのだが、自作のアプリケーションで古いものが結構エラーになっていた。
中でも強烈だったのはDB接続不可能というもの、ID/PWはあっているのに・・・
あとはDatetime型のレンジが変わっているのかオーバーフローしていたり、謎現象だらけでさすがに解消までに時間がかかるので移行前のスナップショットに戻した。
CentOS7の標準パッケージの5.5を使い続けてきたけど、さすがにそろそろ10系にしておくかということで移行。
5.5系ではperconaのxtrabackupが使えたけど、10系では使えなくなったのでMariaBackup導入。
一応バックアップを取りつつ、各種アプリケーションの様子見。
寒いところに一晩おいて充電ケーブル指してなかったので起動すらしない状況に。
その状態で充電ケーブルさしても充電中にはなるのだが1時間立ってもレッドマークで起動に必要な電力足りず。
筐体触るとめっちゃ冷えていたので、とりあえず温める。
温めて10分後に起動してみると無事スリープ状態から復帰。
バッテリーは寒さに弱いので寒いところに放置したのがまずかったか!
仕事でちょっとVPC Flow logsを調査する機会があって、自分のAWSアカウントにも設定してみた。
ただ、何もしてないでも大量にログが出るようだとCloudWatchの料金が掛かりそうで心配で見てみたが、何のインスタンスもなく通信が発生しないような状況だと当然ネットワーク通信もないので出力されない=料金がかからない。
個人利用で大したこともやっていないのならVPC Flow Logsを有効にしても、料金は無視できる程度と判断した。
ただし外から攻撃などでログの量がいきなり増える可能性もあるので、料金は定期的に見ておいたほうが良いのは言うまでもない。
リニューアルしてネットワーク接続不良、再インストール失敗を乗り越えて次のトラブルは謎のプロセスが殺される事態。
Javaのサーバープロセスなのでメモリ不足を疑い、oom killerが発動していることが判明。そんなにメモリきつきつかな?と調査してみたらナントスワップがないのでありました。
取り急ぎ以下のコマンドで2Gのスワップ作成
dd if=/dev/zero of=/swap bs=1M count=2048 chmod 600 /swap mkswap /swap swapon /swap
土日の回復は難しいかと思ったが、24時間以内に返信がありOSインストール中に止まってたらしい。もちろんこちらでは手出しができないことなので直してもらってインストール完了状態にはなった。
全然つながらないと思ってよく見たらIP変わってやがる!今まではIP固定だったのだが、今後は再インストールでIP変わるのだろうか?
スナップショット機能が未だに調整中で提供されていないのだが、いずれまたスナップショットを取るために懲りずに再インストール予定。
今週月曜日に自分のサーバーがメンテナンスとなり、事前情報だと終日停止のようだったが、6時間後に復旧。
ただしネットワークが不安定で落ちるわけがないAWSへのTimeoutなどが頻発するようになった。これでは使い物にならないので乗り換えを検討してしまうほど。
2日後に緊急メンテナンスがあって、これも指定時間帯に再起動が走るというものでいつ使えなくなるかわからないという。。
そのメンテナンスが終わってネットワークがようやく安定してきたので再インストールしようとしたら謎のエラーがでて一切の操作ができない状況になった。
あまりサポートには期待してないのだが、これ以上はどうしょうもないので問い合わせ。さて何週間係るかな(メールのレスポンスが遅いので、最初から長期戦覚悟)
port 9000番は解放されているし、ファイヤーウォールは全部停止してみたし、他のDockerアプリは普通にアクセスできるのに何故かSonarqubeだけアクセスできないという状況。
解決してみれば大したことはなかったのだが、その原因はDBの接続に失敗していて、Webサーバーが起動されてないことであった。docker ps していると普通に上がっているように見えるので気がつくのが遅れた。
まずはきちんとログを見ることだ!基本中の基本を忘れて遠回りしてしまった。
Sonarqubeが内部で利用しているElasticSearchのせいでエラーが出ていた。
max virtual memory areas vm.max_map_count [65530] is too low
よく見るやつではあるのだが、インストールしたままの設定だと引っかかる。
とりあえずの設定だと
sudo sysctl -w vm.max_map_count=262144
再起動したら消えてしまうので/etc/sysctl.confに以下の行を追加
vm.max_map_count = 262144