路地裏 ソース解読研究所: カーネルダンプのスタック情報
ダンプ解析をしつつ、自分の理解を確認するために、カーネルダンプのスタックの見方の基本を書いてみます。間違いを発見した方はぜひコメントに入力しておいてください。 このエントリでは、各プロセスのスタックを見るための基本的な情報を記しておきます。 まず最初にpsでプロセス一覧を取得します。 -------------------- crash> ps PID PPID CPU TASK ST %MEM VSZ RSS COMM 0 0 0 c0322a80 RU 0.0 0 0 [swapper] > 0 1 1 f7e110b0 RU 0.0 0 0 [swapper] > 0 1 2 f7e10b30 RU 0
路地裏 ソース解読研究所: カーネルを覗いてみよう
本日、ダンプを読んでいて思いました。 「そうだ、勉強のためならわざわざ障害が起きたダンプファイルを用意して、ダンプを読む必要はないんだ」ってことに。 ですので、日曜日の朝ではありませんが、「ちょっとした冒険」をしてみましょう。 手元に用意するもの - ML40(crashコマンド入り) - 動作しているカーネルと同じバージョンのkernel-debuginfoパッケージ ML40用のkernel-debuginfoは、 http://ftp.miraclelinux.com:/pub/Miracle/ia32/standard/4.0/updates/unsupported/RPMS にあります。 さて、kernel-debuginfoを入手したら、システムにインストールしてください。 * バージョンはお手元のもので構いません。 ----------------------- # rpm
Linuxでクラッシュダンプを採取(3) 〜 クラッシュダンプは何故とるの？ 〜 : DSAS開発者の部屋
この数日間、Linux でクラッシュダンプを採取する方法について検証していますが、そもそも何故クラッシュダンプを取る必要があるのでしょうか。目的を見失ってしまうのは寂しいのでこのへんで少し確認しておきたいと思います。 ・不具合の原因を解析できる これを聞いて「ええええっ・・」って思う人もいるでしょうね。 原理的には可能だとわかってはいても、実際にやるには気力と根性と感性と時間が必要です(笑) そんな私も「Linuxカーネルの解析ができますっ！」なんてとても言えたものではありません。 それなのに何故クラッシュダンプを採取しようとしているか・・・ それは ・問題発生時に動いていたプロセスを知ることができる ・問題発生時にオープンしていたファイルを知ることができる ・問題発生時のロードアベレージなどを知ることができる ・問題発生時のログを採取することができる ・問題を引き起こしたプロセスが特定で
Linuxでクラッシュダンプを採取(2) 〜 カーネルパニックを起こしてみる 〜 : DSAS開発者の部屋
前回は、カーネルパニック時にkexecでセカンドカーネルを起動できる仕組みまで整えてみました。 今回は、実際にセカンドカーネルを読み込ませてみて動作確認をしてみたいと思います。 kexec -p --args-linux --elf32-core-headers --append="文字列" ファイル名 オプションの意味は以下の通り。 -p パニックが起きたらセカンドカーネルを起動する --args-linux Linuxカーネルスタイルのオプションを使用する --elf32-core-headers elf32形式でコアヘッダを用意する --append=STRING カーネルに渡すコマンドラインオプションを指定する ということで、こんなコマンドを組み立ててみました。 kexec -p \ --args-linux \ --elf32-core-headers \ --append="r
Linuxでクラッシュダンプを採取(1) 〜 kexec + kdump を使ってみる 〜 : DSAS開発者の部屋
専用パーティーションを切らずにシステムを構築してしまったがために、クラッシュダンプを採取できなくて苦しんでいる人（って私ですが）にとってはとっても魅力的な仕組みがカーネルに取り込まれたみたいです。導入手順も Documentation/kdump/kdump.txt に非常にわかりやすく書かれているので、比較的スムーズに組み込むことができそうな予感がします。 kexec の機能を利用して別のカーネル（kdumpを組み込んだもの）を起動すると、/proc/vmcore から元のカーネルのクラッシュダンプを採取できるというものなので、通常利用するカーネル（以下、ファーストカーネル）と、パニック時に動き始めるカーネル（以下、セカンドカーネル）の二つのカーネルを作る必要があります。 以下、kdump.txt より抜粋 A) First kernel or regular kernel: -----
路地裏 ソース解読研究所: 最強の割り込み
カーネルストール。これは厄介な敵です。 カーネルPANICならば、最近のカーネルに備わっているdump機能が働いて、カーネルダンプが取れたりするので、さっさとrebootするのを待つばかりです。 一方でカーネルストールの場合、よくあるのはログインしようとしてもなぜかプロンプトが返ってこないとか、キーは入力できないけどマウスカーソルの位置だけ動くとか、微妙感漂う状況に陥ることがあります。 今日はそんな時の強い味方、NMIについて調べてみましょう。 まず、NMIって何でしょう。一般人の味方 Googleで調べてみます。 http://www.nifty.com/webapp/digitalword/word/020/02083.htm こんなページがひっかかりました。何々? 「Non-Maskable Interrupt - マスク不可能な割り込みのこと。ソフトウェアでこのNMIを禁止すること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxでクラッシュダンプを採取(4) 〜 セカンドカーネルがやるべきこと 〜 : DSAS開発者の部屋