Server

[PR]

×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
could not delete the default bridge network: network bridge has active endpoints で Docker が起動できない場合
Docker Daemon が動いていないという連絡を受けてサーバを見たら確かに動いていない。$ sudo service docker start したら OK と出るも、$ service docker status したら止まっていると表示され頭をかかえる。/var/log/startup/docker.log をチェックしたところ、以下のエラーが出力されていた。
```
/var/run/docker.sock is up
INFO[0000] [graphdriver] using prior storage driver "aufs" 
INFO[0000] Graph migration to content-addressability took 0.00 seconds
INFO[0000] Firewalld running: false
FATA[0000] Error starting daemon: Error initializing network controller: could not delete the default bridge network: network bridge has active endpoints
```
Docker fails to create network bridge on start up · Issue #18113 · moby/moby に同じような話が上がっており、aboch さんの以下の投稿が役に立ちそうだった。以下に私が翻訳してみたものを載せる。原文は 1つめ 2つめ

aboch commented on 2 Dec 2015

大体の場合、この問題は /var/lib/docker/network/files/local-kv.db の内容がおかしいと発生します。

@mavenugo さん docker/libnetwork#687 に書いた内容が何が問題なのかを理解するための助けになると思います。docker#17939 (comment) に前に書いたように※

aboch commented on 2 Dec 2015

@Chili-Man さん, @dvanbuskirk さん, @sheldonkwok さん

このような問題に当たった時、/var/lib/docker/network/files/local-kv.db の内容を私に共有していただけますか? これを拝見したいのです。

この問題の対応として、これを確認したうえで、このファイルを削除して Docker Daemon を起動すればよいはずです。

※ ここの翻訳、自信ない

とりあえず、上述の通り /var/lib/docker/network/files/local-kv.db を消せば動くようだ。実際、私の場合 /var/lib/docker/network/ をリネームし (= /var/lib/docker/network/files/local-kv.db はなくなる) docker の再起動を試みたらうまく動いた。
PR
[愚痴] AWS EC2 の EBS ボリュームの変更は気軽にはできない

大分前の話になるが、AWS EC2 (Amazon Web Service / Elastic Compute Cloud) の EBS (Elastic Block Store) ボリュームのサイズ変更がインスタンスに EBS をアタッチしたままできるようになった (公式の手順書)。これで気軽に色々試せるなぁと思ったのだが、実はそんなことはない。会社の後輩が気軽にボリュームサイズを変更したうえで頭を抱えていたのである。

ひよこがどうしたのか、と声をかけたところ絶望感を漂わせながら彼は「ボリュームサイズを増やしたはいいだが、そのサイズでは足りなかった。ならば、と再度増やそうとしたら『6時間待たなければ変更できないよ』と言われた」と言うのである。ちゃんと読まないと意識し難いが、EBS ボリューム変更時の制限 - Amazon Elastic Compute Cloudには一度変更したボリュームに追加の変更を適用する場合は、6 時間以上待ちますと記述されている。それでも、急いで変更を再度実施したいとすればボリュームのスナップショットを取得し、そこからボリュームを再度作るしかない。

AWS のサービスはどんどん試せる印象があるが、実はこんなこともある、という愚痴。
[愚痴] service nginx reload しても設定が再読み込みされない?
権利的な話とか

Creative Commons Attribution Share Alike 4.0 で公開されている資料の訳を載せている。この記事も同様のライセンスとなる。

nginx の設定再読み込みが思い通りに行かない

nginx の設定を可能な限り nginx を止めずに変更したい。SSL 証明書の更新とか、設定の追加とか。

しかし、どうにもうまくいかない。

# nginx とした後、設定ファイルを書き換えて # nginx -s reload でもだめ。~/newNginxConf/nginx.conf に新しい nginx.conf を置いて # nginx -c ~/newNginxConf/nginx.conf とかしてもダメ。

一応、 stop/start すれば問題なく反映はされるのだが……

関係するサイト

CommandLine | NGINX (Creative Commons Attribution Share Alike 4.0 で公開されている) の Loading a New Configuration Using Signals のあたりが関係するか。簡単に訳すと以下のようになる (翻訳元の版は 2017/3/6 日版)。
シグナルを用いて新しい設定を読み込む

NGINX はいくつかのシグナルもサポートしています。なので、これを使って NGINX を操作することもできます。

多くの場合、15番 (SIGTERM 終了) を NGINX の終了のために送信するでしょう。
```
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2213  0.0  0.0   6784  2036 ?        Ss   03:01   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
```
しかし、より注目すべき使い方があります。NGINX の設定ファイルを無停止で差し替えることができます (これをやる前に新しい設定ファイルのテストをお忘れなく)。
```
2006/09/16 13:07:10 [info]  15686#0: the configuration file /etc/nginx/nginx.conf syntax is ok
2006/09/16 13:07:10 [info]  15686#0: the configuration file /etc/nginx/nginx.conf was tested successfully
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2213  0.0  0.0   6784  2036 ?        Ss   03:01   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
```
NGINX が HUP シグナルを受け取った際、NGINX は新しい設定ファイルを解析します (引数として新しいもののパスを与えていなければ default のものを解析します)。解析に成功すれば、新しい設定ファイルを適用します (例えばログファイルを開きなおしたり、Socket を listen しなおしたり)。成功すれば NGINX は新しい Worker Process を起動し、古い Worker Process は安全にシャットダウンします。古い Worker によって Listen されていた Socket は閉じられますが、クライアントの動作は続行します。最終的にはすべての古い Worker がシャットダウンされます。もし、NGINX が新しい設定ファイルの適用に失敗すれば、古い設定ファイルのママ動作を続けます。
どうもこの Worker の終了・作成がうまくいっていない?

似たような話をしているサイト
- nginxでrestartしたのに設定が反映されない時はnginx -s reload - 以下省略!
- nginxにreloadシグナルを送っても設定を再読み込みしてくれなかったりなかなかKILLされなかったり - There's an echo in my head
jq コマンドが使えない時に泣く泣くなんとかする方法

jq コマンドが便利だ。日本語で解説している記事：jq コマンドを使う日常のご紹介 - Qiita

だが、見ての通りどこででも使えるコマンドではないのが最大の欠点である。使いたいのに使えない時、ひよこがよく使うコマンドをいくつか。

tr コマンド (ITpro さんの解説)

まずはこれで各要素を行に分割する。$ echo jsonfile.json | tr ',' '\n' とでもしてやればよい。

python -m json.tool

python が入っているならこっちを使った方が楽。$ echo jsonfile.json | python -m json.tool これで整形してもらえる。

grep コマンド (ITpro さんの解説)

これで必要なものだけを抜き出す。$ echo jsonfile.json | tr ',' '\n' | grep 'age' 等とすれば age だけ抜き出せる。重ねがけなどもできるのでうまく使う。

head コマンド / tail コマンド (ITpro さんの解説 head / tail)

これでさらに必要なものだけを絞り込む。tail -200 catalina.out 等とやると末尾200行だけ抜き出せる。head -200 catalina.out だと逆に先頭200行だけ抜きだせる。json を力技で読み取る時以外にも利用できるのでおいしい。

8行目だけ欲しいの、という場合は head -8 catalina.out | tail -1 だ。

なお、このような小手先では解決できない場合、jq をインストールするなり、適当なブラウザの開発者ツールで読み解くなり、専用のパーサを頑張って作るなりした方が良いと思う。あくまで即興用。
シェルスクリプトでちょっとずつ待ち時間を延ばす
リクエストの結果を待つ際、徐々に待ち時間を延ばしたいことがある。シェルスクリプトでそれをやりたい、という話が挙がったので書いてみた。似たようなことをまた聞かれた際に返すよう。
```
HIYO=2
while [ True ] # これをすると無限に続ける
do
  sleep `echo $HIYO`s
  echo hiyohiyo $HIYO # このあたりで結果取得処理を行い、結果が出ていたらループ脱出処理
  HIYO=`expr $HIYO \* 2`
done
```