2007年9月13日木曜日

core dumpファイルを吐かせる

■設定確認編
Segmentation faultが起きていたLinuxでcoreファイルを検索。
非効率的だが何処にあるか解らんので、Linuxのディレクトリの一番上へ移動。でそこで「今いるディレクトリ以下にあるcoreという名前をファイルを探す」コマンドを実行
-find . -name core
が、dumpと思われるファイルは引っかからず。なぜだ・・・。

ちょっとLinuxに詳しい友人にメッセ経由で聞いてみると、「core dumpが出来過ぎてHDD圧迫する事があるから吐かない様にしてる事は多いよ。設定で変更出来るはず」というお言葉が。
そこでどこでその設定をしてるか調べてみた所IT Proの記事が見つかり、下記コマンドで出来る様だ。
ulimit -a
んで実行結果の中でcore dumpに関係してそうな値が
core file size (blocks, -c) 0

となっている。ゼロじゃそりゃ吐かないべ・・・。あともう一個コマンド発見
sbin/sysctl -a
実行結果の中で関係してると思われる場所
kernel.core_pattern = core
kernel.core_setuid_ok = 0
kernel.core_uses_pid = 1


これ記事書いてて気付いたけど以下のコマンドだと直に値を見られる見たい。
sysctl kernel.core_pattern
sysctl kernel.core_setuid_ok
sysctl kernel.core_uses_pid




■設定変更編
上記の結果を受けて設定変更をする。変更する場所は
1.kernel.core_setuid_okを1にする。
2.core file sizeを2048blockにする。(2048の値は適当に選んだ)

1を実行するコマンド
sysctl -w kernel.core_setuid_ok=1
2を実行するコマンド
ulimit -c 2048

これでいいはず。あとCoreファイルがはかれる場所も確認しないと。
てかたまたまこんなblogを発見。
ノウアスフィア探検隊:core解析メモ

初期設定ファイルが/etc/sysctl.conf

2007年9月12日水曜日

Segmentation faultが一杯。

最近エラーログに多い下記のerror文章
[Mon Sep 10 23:05:46 2007] [notice] child pid 19800 exit signal Segmentation fault (11)

まぁお約束というか差し当たりというかぐぐってみる。そうするとはてなのサイトが引っかかった。意味としては


  • Segmentation違反。メモリアクセス違反。アクセスが許可されていないメモリ領域を参照すると発生。

  • エラーログに上記のMessageを残し、coreを吐いて異常終了。

  • 原因としては、Nullポインター、未初期化ポインタでのアクセス、スタックオーバーフロー等。

  • 配列の範囲外アクセスでも発生。

  • 希だがOSレベルのバグ、メモリモジュールの不具合による場合もある。


で続いてhpの公式サイト

  • プログラムは起動時にメモリ領域を定義。その領域外のメモリ領域にアクセスしようとすると発生。

  • 宣言した配列の範囲を超えて添え字付けると発生。

  • カーネルの処理能力を超える局所変数、無限再起でも発生。



ぬぅ・・・無責任だがハードウェアの故障が原因だったら楽だなぁ・・・。
調査中に■Manpage of COPEにて以下の記述を発見。
どうやらSegmentation faultがSignal11で起きた際は「coreファイル」なるdumpが生成されている模様。これを解析する事でSegmentation faultが起きた原因は調査する事は出来そう・・・だが、どうやるんだコレ。

その前にまCoreファイルを探さないと。

2007年9月3日月曜日

PerlのWARNINGをなくす

perl -w hoge.pm

Perl開発者が死ぬまでに一番たたくコマンドじゃなかろうか('A`)
これでエラーを見つけて修正して、やっとこさ動くプログラムが完成する。しかし正常動作してもこのコマンドを叩くと警告とかが出てくる。

■警告内容
・その1.Use of uninitialized value in hash element at hoge.pm line 123
・その2.Use of uninitialized value in substitution (s///) at hoge.pm line 456

エラーじゃないしプログラムもちゃんと動くので今まで無視してきたけど、ちょっと気になってきたので直してみる。

■その1の警告の解決方法
その1の場合は「変数としては存在するけど、それに値が入ってるのか入ってないのか解らない。だから値を確認するか空の値を入れておけ」という旨なので、以下の赤い部分の様なモノを追加してあげる。そうすると値がNullでも確実値が入っているか入ってないかが解るので、警告文が消える。
意外と忘れがちなのが「$key」の部分。値がNullであればわざわざ入れる必要ないのだから、if文でチェックしてnextしておく。
$HOGE={};
foreach my ($key,$value)=split(/\=/,$line,2){
next if( !$key );
$HOGE->{$key}=$value || '';
}


■その2の警告の解決方法
ぱっと見で解る人がいると思うけどこれは正規表現関係。Perlで正規表現って結構強力で頼れるんですよね・・・。
問題となるのは正規表現を何個か連発した時。
エラーの内容としては
「正規表現って値をごちゃごちゃいじるけどいじった結果って解らないよね?値が消えちゃってる可能性ない?ひょっとしたら今行った正規表現で、値が空になってね?」
と言う警告。なのでコード上は余り綺麗じゃないが下記の様に修正。値が入っている事を確認してから処理。値が入ってなければ処理する必要もないんで問題なし。
$value=~s/ABC/xxx/g if( $value );
$value=~s/EFG/yyy/g if( $value );
$value=~s/DEF/zzz/g if( $value );

これで正規表現中の警告が消える。

警告なので直す直さないは個人の自由だけど、errorログが綺麗になるんで、暇とか余裕があったからやってみた

NFSのエラー「nfs_notify_change」

サーバが不安定な時、LinuxのOSログであるMessageログに出ているNFS関係と思われるエラー。
ネットで探してもいまいち解決策が解らず。取り敢えず関係の有りそうなサイトは幾つか見つけたので、それと併せて調査。
なお問題が起きてる環境は
NFSサーバ:Windows 2003 Server
NFSクライアント:Red Hat Linux ES 3

■問題のエラー
kernel: nfs_notify_change: revalidate failed, error=-116
kernel: nfs: server 123.156.789.012 not responding, still trying
123・・・の部分はIP。

■参考URL
http://search.luky.org/linux-kernel.2003/thrd73.html

■■■調査内容■■■
取り敢えず「error=-116」から調べてみる。エラー番号だからネットで探せば直ぐ解るだろうと思ったら中々出てこない。
仕方ないので上記URLのメーリスをじっくり読む事に。



以下は現在調査中につき鵜呑み禁止、突っ込み&助言大歓迎
何となくだが読んでいるとエラー番号166というのは「ESTALE」という事を意味している?
仮にそうだとしてこの「ESTALE」で検索してみると以下のURLがヒットした。

外部URL:[9454] Re^5: NFSのエラー
>「ユーザ資源の実体が存在するマシン側」のファイルシステムが
>再編成されたことにより、NFSで内部的な混乱(内部矛盾?)が発生

外部URL:nfs(7)
>クライアントがマウントすると各ファイル/ディレクトリ 用の ファイルハンドルをクライアントに発行
>サーバ側でファイルが消去されると、 そのファイルハンドルは失効 (既知のファイルとの関係を断たれる)
>サーバは errnoに [ESTALE] をセットしてエラーを返す。

最初のURLの情報と合わせて考えると「NFSサーバ側で、被mount領域にあるファイルに変更を加えるとエラー」って事なのか?

>サーバがダウンしている、あるいはアクセス不可能な状態にあると
>「not responding: still trying」のエラー

まぁ予想通り。肝心な「アクセス不可能な状態」に言及がない。

> nointr オプションでマウント・・・サーバが回復するまで シグナル受領可能状態で待機。
>softオプションでマウント・・・ クライアントプロセスは無限に待つことはなくエラーを返す

今確認してみたらNFSのmountに「nointr」って指定してる。でもこの部分は直接は関係なさそう。
softオプションを付加した際に返されるエラーて何だろう・・・。