Nginxで「pread() read only xxxx of xxxx from xxxx」 エラーが表示されたときの対応と、open_file_cacheとの関連
OpenRestyで動的生成されたコンフィグファイルをLuaで読み込んで云々、という処理を行っているのですが、
その際Nginx側で表題の「pread() read only xxxx of xxxx from xxxx」といったエラーが表示される事案がありました。
状況まとめ
- 特定の環境のみ表示
- 突然エラーが出始めた
- 同じロジックで、過去にエラー表示されたことはない
- しばらく(1分くらい)するとエラーでなくなる
ググる
以下の２つのリンクが引っかかりました。
引用ですが
Investigating my Nginx configuration I found this may be related to the files cached using open_file_cache option on Nginx. According to Igor Sysoev (creator of Nginx) on this forum it was caused because the file was not updated atomically. Temporary disabling open_file_cache fixed the issue.
とありますね。
どうやら「Nginxでopen_file_cacheを利用していて、かつそのキャッシュの対象ファイルがアトミックに処理されないとエラーになる」ようです。
open_file_cacheを無効にすれば解消しそうですが、無効にはしたくないですし原因不明のまま対応するのも気持ち悪いのでもう少し調べてみます。
コンフィグ生成コード
言われてみれば、その辺りコンフィグファイルを動的生成するときにはあまり気にしていませんでした。
Consulでイベント受信して生成しているのですが、ファイルを出力する現状のコードは以下のような感じです。
def write_file(self, file, data): directory = "/path/to/config" if not os.path.exists(directory): os.makedirs(directory) fname = directory + file with open(fname, mode = 'w') as fh: fh.write(data)
そこで、以下のようにアトミックにファイルを生成するように変更してみました。
import tempfile from stat import S_IRUSR, S_IWUSR, S_IRGRP, S_IROTH def write_file(self, file, data): directory = "/path/to/config" if not os.path.exists(directory): os.makedirs(directory) fname = directory + file with tempfile.NamedTemporaryFile(delete=False) as tfh: tfh.write(data) temp_fname = tfh.name # 新しくファイル作っているので、適切なパーミッション付与しとく os.chmod(temp_fname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH) # move os.rename(temp_fname, fname)
この対応でエラー無く処理されるようになりました！ 🙆
急にエラーが発生した原因
単純に、いままではファイルバッファ内に収まっていて問題にはならなかったのですが、
コンフィグファイル肥大化によりバッファが溢れてアトミックに処理されなくなっただけでしょう。
まとめ
あんまり見たことがないエラーだったので久々に記事にしてみました。
この問題はLuaに限らず普通のファイルアップロードなどでも発生するので、open_file_cacheを利用する際には気をつけましょう！
2017年振り返りと2018年
2017年
いろんなことがあったけど、振り返ってみると自分にとっては総じてあまり良い年ではなかったなーと思う。
前厄
でした😇
仕事
総評
言い訳にはなるのだけど、運用しながら新しいことをやるというのはとても難儀だった。
会社としてもとにかく動きが激しくなりはじめ、こなすことで精一杯。
自分としてやりたかったことが全然出来なかったのが悔やまれる。
あっ、あと昨年は病欠しなかったみたいです。小学生か！
ロール
なんとなくチームリーダー的なことをしてたんだけど、 中旬あたりからid:muddydixon がJoinしてくれてからは自分のロールも変わったこともあり現在はほぼおまかせ。
マネージメントやチームビルディングに関してはもともと得意分野ではなかったのだけど
「どうすればチームとしてプロダクトに貢献できるか／エンジニアがやりやすい環境をつくれるか」
を考えるのは体験としてはなかなか面白かった。
上手く行ってたかどうかは不明だけど、悪くはなかったとは思っている。
家族
息子も娘も順調に育ってくれているのでありがたい。
息子は友達少なそうなのが心配…
娘はマイクラ動画とオデッセイ動画を見すぎなので控えましょう。
奥さんは最近やさしくしてくれます。ありがとう〜
2018年
本厄です😇
仕事はとにかく面白くなりそうなんだけど、リソースが本当厳しい。
今まで以上に頑張らないといけないのだけど、完全にこれはチャンスでもあるので手を抜かずにやっていきたい 💪
小諸そば派が富士そばを語る
この記事は 富士そば Advent Calendar 2017 の20日目の記事です。
ところで、今年ももう終わりだというのにこの記事がこのブログの今年初の記事ですよ。サボりすぎててひどい（一応技術的なのはQiitaとかに書いたりはしてるんですよ…）
コロッケそば
コロッケそば好きなんですよ。あるとついつい頼んでしまう。
ちなみにそばで一番好きなのは春菊天そばです。置いてるとこなかなか無いのですが…
僕と富士そば
先にお話しておくと、実は僕は小諸そば派なんですね。1
あっ、そういえば一人で 小諸そばAdvent Calendar 2017 というのをやってたりしています。楽しい。
ただもちろん富士そばも好きですよ。何派だっていいじゃないですか。そば好きに国境はありません。
で、今回久々に富士そばを頂いたんですね。最近小諸そばしか食べてなかったので、より富士そばを味わうことができました。
すると「あっ、なんか懐かしい味がする」と思いました。
よくよく味わってみると 立ち食いそばの王道 的なテイストなんですよね。富士そばって。
自分が高校生の頃、諸事情により半年くらい電車通いで通学してたんですけど、花巻駅で乗り換え待ちしている時に駅構内にある立ち食いそば屋さんの匂いによく釣られて食べてました。そこの立ち食いそば屋さんの味にすごく似てるような気がするんですよね。めっちゃ濃いい麺つゆベースで本当美味しかったなぁ。
2016年振り返りと2017年
昨年をあらためて振り返ると、個人としては30代のワーストとなる年だった気がする
（あくまで個人としての話です）
ワーストの理由
- インプット／アウトプットともにほぼ０に近かった（特に登壇は０）
- 家庭についてもあまりお手伝いできず、家内に負担をかけてしまったかも
2015年のサービスローンチが終わって、2016年は少しは楽になるかな−と思いきや
より忙しくなってしまいいつの間にか今日に至る、という感じ。
忙しいのは自分のせいなので言い訳にせず、猛省します。
ロールの変化
そんなに大層な話でもないが、立場的にリーダーっぽいタスクが増えた。
昨年はいかにチームとしてうまく回せるか、というところを重点に置いて仕事を進めるように心がけていた。
独りよがりにならないようにチームメンバーと1on1を行ったり、全体の開発フローの提案では合意を取って進める（さらに改善できるところはする）、などを行っており、そこはうまく回っているように感じている。
ただ自分がクリティカルパスになりがちなことが多かったので
任せられるところは優秀な同僚に振りつつ、自分はもっと上のレイヤーにかかわらないとな〜と思っているところ。
2017年
特にこれといった目標があるわけではないけど、今年は40歳になる節目の年だし
忙しいを言い訳にせず何か一つでもやり遂げたい（やりたいことはたくさんある）。
仕事も家庭も充実した一年にしたい
Nginx実践入門
nginx実践入門 (WEB+DB PRESS plus)
posted with amazlet at 16.01.31
この度はご恵贈いただきましてありがとうございます。
途中からですが、自分もレビュアーの一人として参加いたしました。
本書についての雑感
Nginx入門ではなく、Nginx実践入門というタイトルからも分かる通り
より実践向けの内容となっています。
ターゲット層としては
「一通りNginxを触ったことがあるが、さらにNginxを使いこなしたい人向け」
といったところでしょうか。
特に後半
第5章 安全かつ高速なHTTPSサーバの構築
第6章 Webアプリケーションサーバの構築
第7章 大規模コンテンツ配信サーバの構築
第8章 Webサーバの運用とメトリクスモニタリング
辺りの内容が素晴らしいです。
5章、HTTPS周りではセキュリティ／パフォーマンスについても考慮されており
Nginx＋HTTPSで配信している環境では必読かと思います。
6章、Nginxでよく利用されるパターンと思われる、リバースプロキシ周りのお話です。
普段よく目にするプロキシ周りのディレクティブですが、
「この設定値はどのように決めたらよいか」という説明が丁寧に説明されていて
非常に勉強になりました。
7章、大規模コンテンツ配信、主にLBやキャッシュ周りのお話です。
キャッシュ戦略の話や配信クラスタの話など、とても興味深く読むことが出来ました。
8章、運用周りのお話です。モニタリングやアクセスログについて、
きちんと運用しようとすると意外と大変だったりします。
その辺りのリファレンスや実際の手法が書かれていて参考になりました。
また全体的に
単純なリファレンスとして書かれているのではなく
「なぜこういうことをするのか」
「そのためにはどういう設定をすればよいのか」
「この設定はどのような事を考慮して値を決めればよいのか」
が丁寧に書かれていて非常に読みやすかったです。
このように、実践の名にふさわしく
著者が今まで培ってきた運用ノウハウがギッシリ詰め込まれています。
「他社では実際にどのような設定をしているのか」
「どのような運用をしているか」
といったところはとても参考になりますし、普段から気になるところでもあります。
Nginxを使い倒している会社の知見を得られるというだけでも
本書を読む価値はあると思います。
レビューについて
自分は主に９章／１０章のlua関連の箇所をレビューさせていただきました。
こういった書籍のレビューに参加するのは初めてでしたので
どの程度口を出して良いかの匙加減が難しかったのですが
いくつか反映していただきました。
貴重な体験ありがとうございました。
まとめ
Issue上のやり取りを遠くから眺めていたのですが
「出来るだけ新鮮な情報を載せたい」
「妥協せず良い情報を載せたい」
という意気込みを感じました。
そしてそれが反映されている書籍だと思います。
是非手にとって、実際にそれを感じていただきたいです。
また著者のお二方、関係者の方々、お疲れ様でした！
2015年振り返りと2016年
※仕事納めしながら書いてる
今年はまれに見る激動の年だった。
とくに後半は何してたかもあんまり覚えてない。
登壇
自分にしては例年よりか登壇して喋ったような気がする。
しかも嬉しいことにお声がけ頂くことも。。
- CROSS 2015: はやぶさ2開発者に聞く〜一度きりのテスト対策〜
- TV連動勉強会vol1: TV連動サービスのリアルタイム通知を支える技術
- Monitoring Casual Talks #7: shinken monitoringについて真剣に調べてみた結果
- YAPCAsia2016: Docker３兄弟
- Itamae Meetup#1: Chef SoloからItamaeに完全移行した話＋
ただ、話すのがそんなに得意ではないのもあり
毎回トーク後に反省してました…
もっとうまく喋れるように来年はがんばります。
仕事
前半にHAROiDに転籍してから
無事リリースまで漕ぎ着けることが出来た。よかった。
今年はほぼこのリリースに注力した年だった。
完全に言い訳になるが、目の前の仕事が忙しすぎてほとんど技術系への投資が出来なかったのは反省。
本もほぼ読めてない…
2016年
おそらく会社としても自分としても転機になりそうな年。
モチベーションはかなり高いので攻めの姿勢でがんばります！
YAPC::Asia 2015で「Docker３兄弟」というお話をしました＋QA補足 #yapcasia
※2015/08/29 追記
現在DockerToolboxでVirtualBoxもインストールすると最新の5.0.2がインストールされますが
このバージョンがDockerMachineと相性が悪く、VMが起動しないという罠があります。
https://github.com/docker/machine/issues/1716
VirtualBoxのバージョンを5.0.0に下げるか、
こちらから次期テストバージョンの5.0.3をインストールしましょう。
まずはじめに、足を運んでお聞きいただいた皆様ありがとうございました。
30分(トークは20分)にこれら３つのツールを紹介するにはボリュームが少し多すぎた感があり
きちんと伝えたいことが伝わったかどうか不安。。
また、QA時に英語で質問されテンパってしまってきちんと回答できず、質問していただいた方に大変申し訳なく思っております。。
QA時に回答できなかった分について補足します。
※kitematicについては英語でQAされたもので、きちんと理解出来ていない可能性があるので２通りの回答してみます
Q. kitematicでlinux上のリモートホストを管理できる？
A. 現在は出来ないようです。issueにはあがっているのでそのうち対応するかもしれません
Q. kitematicはlinux os上で動く？
A. 現在は出来ないようです。issueにはあがっているのでそのうち対応するかもしれません。
Q. docker-machineでREST APIはある？
A. 現在は出来ないようです。がロードマップ(c/sアーキテクチャ)には記載されているのでそのうち対応するでしょう。
あと一つ強調し忘れていたこととしては
「docker composeは冪等である」ということです。
どの環境でもdocker-compose up すれば動く！最高！！
開発環境やインフラでは冪等性が大事だと思っています。
docker-composeはその手助けをしてくれるでしょう。
