ps と grepでツボった話 <-- 初心者並 orz

反省箇所多し:自分への戒めで、晒しておこう。

発端は、なんか知らんけど、nohupとrbenvの相性が悪い、かな、と思った。最初はきちんと動いているのに、十数分後から

sh: 1: 1: Too many open files
nohup: 出力を ‘nohup.out’ に追記します

このメッセージが画面に溢れる。nohup.outを見ると

rbenv: cannot find readlink – are you missing GNU coreutils?
/usr/local/bin/rbenv/libexec/rbenv: line 22: /dev/null: Too many open files
/usr/local/bin/rbenv/libexec/rbenv: cannot make pipe for command substitution: Too many open files

この繰り返し。1秒間に10回はシェルを起動、実質的なマシンフリーズ。わからん。ツボった。

元を辿ったら、理由がわからないけれども、

ps -ef | grep puma | sed ‘/grep/d’ | grep -c puma

でpumaの起動を確認。別窓でrailsサーバは起動済み。それなのに、プロセス数が0で返ってきて、サーバが落ちてると勘違いして、nohupの起動コマンドが起き出す、で、同じポートを指定するから、多重起動をブロックされ、その後プロセス起動の無限リトライが始まる、とここまでは追い詰めた。

pumaは間違いなく動いている。クライアント窓からアクセス可能。grep puma自身のプロセスをブロックするために、sed ‘/grep/d’でその行を削除。正常動作では1が返ってくるのに、突然0が返り出す、この原因がわからない・・・psが走ってるプロセスを拾ってくれない、みたい。

半日潰した。やり方変えようかなぁ。何が起きているんだろうか。プロセスのrun状態を見るのに、何かキャッシュが入ってる?kernel読まないとダメ?

ってか、これ、ダミーホストで完全な治具だから「私には解決できません!」と諦めるのがも正解かも。

こういうの、悔しいんだよなぁ。負けるが勝ちか?
問題を解決できないこと自体が悔しい。

意味もなく、自転車でぶらつくことにする。


いた。虫がいた。
if(++ret == count){
pclose(fp);
return ret;
}

としないと、パイプを開きっぱなしになるのに、

if(++ret == count) return ret;

なんて書いていた。初心者みたいなバグ。

cannot make pipe のメッセージを見落としていました。

バグに煮詰まったら、そばにいるプログラマを捕まえて、状況説明すると、だいたい自分で気づくってのがよくある話で・・・。私の場合にはそれがネットだった、ってことね。

反省箇所は、まだある。一年半前に書いた治具用のコード。自分専用だから、ちょっとテストランしてそのまま使っていた。よくよく読んでみると、popenのエラーを返すのに0を使っていて、カウント数0はサーバダウンの時に戻る「処理正常」の値。これが被っていた。ど素人か、みたいなミス。
賄い飯みたいなものだけれど、だからって適当に書いていると、こういうことになる。粗忽だ。
orz