crashコマンドではダンプファイルを解析するのに使用しますが、ダンプがなくても現時点のカーネルの状態をcrashのlive systemで確認することができます。 crashのlive systemではカレントプロセスのバックトレースを表示させることができませんが、今回はそれを無理矢理 表示させる方法を紹介します。 以下のコンフィグを有効にしたカーネルを作成して起動します。 Kernel hacking ---> Kernel debugging このコンフィグを有効にするとデバッグ情報が入ったカーネル(vmlinux)が作成されます。このカーネルを/bootなどに置いておきます。今回の場合はvmlinux-2.6.15-testにしました。 このときのカーネルで再起動して以下のコマンドを実行します。 # crash /boot/vmlinux-2.6.15-test cras
本日、ダンプを読んでいて思いました。 「そうだ、勉強のためならわざわざ障害が起きたダンプファイルを用意して、ダンプを読む必要はないんだ」ってことに。 ですので、日曜日の朝ではありませんが、「ちょっとした冒険」をしてみましょう。 手元に用意するもの - ML40(crashコマンド入り) - 動作しているカーネルと同じバージョンのkernel-debuginfoパッケージ ML40用のkernel-debuginfoは、 http://ftp.miraclelinux.com:/pub/Miracle/ia32/standard/4.0/updates/unsupported/RPMS にあります。 さて、kernel-debuginfoを入手したら、システムにインストールしてください。 * バージョンはお手元のもので構いません。 ----------------------- # rpm
この数日間、Linux でクラッシュダンプを採取する方法について検証していますが、そもそも何故クラッシュダンプを取る必要があるのでしょうか。目的を見失ってしまうのは寂しいのでこのへんで少し確認しておきたいと思います。 ・不具合の原因を解析できる これを聞いて「ええええっ・・」って思う人もいるでしょうね。 原理的には可能だとわかってはいても、実際にやるには気力と根性と感性と時間が必要です(笑) そんな私も「Linuxカーネルの解析ができますっ！」なんてとても言えたものではありません。 それなのに何故クラッシュダンプを採取しようとしているか・・・ それは ・問題発生時に動いていたプロセスを知ることができる ・問題発生時にオープンしていたファイルを知ることができる ・問題発生時のロードアベレージなどを知ることができる ・問題発生時のログを採取することができる ・問題を引き起こしたプロセスが特定で
本日、(既に昨日ですが)、第65回のYLUG(in 恵比寿ガーデンプレース)に参加してきました。 話の内容については、非常に面白く質疑応答も白熱していました。これに関しては別エントリで書きたいと思います。 ですが、今日のYLUGのmixiのネタでは、私のカーネルダンプのお話とは全然絡めません。 と、思いきや、たまたま座った隣の席には、IntelのOさんがいらっしゃるではありませんか。 最近、Itaniumのマニュアルを配布されているのをメーリングリストとかでよく拝見していたところでしたし、後でお話したところ、弊社にも送っていただいていたようです。すいません。気づいていなくて。 しかし私は気づいたのです。 「おばあちゃんは言っていた。32bitを制するものが64bitを制するものだ」と....。 いや、冗談です。そんな最新アーキテクチャに強いおばあちゃんは居ません。 しかし、今、私が読もうと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く