第674回 カーネルのクラッシュ情報を解析する | gihyo.jp
第673回の「カーネルのクラッシュ情報を取得する」では、カーネルクラッシュ時に情報を収集する仕組みを有効化しました。得られた情報は活用しないと意味がありません。今回はその中身を解析する方法を紹介します。 デバッグパッケージのインストール 第673回では、意図的にシステムをクラッシュさせることで、dmesgとvmcoreを取得しました。カーネルが今際の際に次につながる情報を残してくれたのです。「しかしながらあのクラッシュが最後のpanicだとは思えない。もし、同じカーネルが続けて使われるとしたら、あのpanicの同類が、また世界のどこかへ現れてくるかもしれない……」 最初に行うべきなのは、前回紹介したように問題発生時のdmesgを読むことです。これである程度、状況の絞り込みは行えますし、運が良ければ原因がわかることもあります。しかしながら、dmesgだけだと「問題が起きた場所」はわかっても
第673回 カーネルのクラッシュ情報を取得する | gihyo.jp
Linuxカーネルも人類が生み出したものである以上、既知であれ未知であれなんらかの不具合を抱えています。そしてそれは「都合の悪い時」に限って顕在するものです。今回は「やたらとカーネルがフリーズする」不幸な星のもとに生まれた人に向けて、カーネルがクラッシュしたときのデバッグ方法を紹介しましょう。 カーネルだってつらいときはあるんです Linuxカーネルには「クラッシュダンプ」と呼ばれる仕組みが存在します。これはカーネルがどうしようもない自体に陥ったとき（＝panicしたとき）、システムを再起動する前に障害収集用のシステムを起動し、現象発生直後のカーネルのメモリーをストレージに保存する機能です。これを使えば、panic時の原因を追求することが可能です[1]。 UbuntuをはじめとするLinuxディストリビューションにとって、Linuxカーネルはまさに「縁の下の力持ち」と言える存在です。
Linuxカーネルの起動時トレースの話 - Qiita
カーネル起動時トレース Linuxカーネルの起動処理は、様々なことが行われるのにそれをデバッグする方法はprintkだったり、逆にkgdbを外部デバッガから繋いだりと、結構な手間がかかっていました。カーネルが起動してしまえば、ftraceにperf, BPF, systemtapと複数の手段が使えるのに、起動時のデバッグは細かいことが出来ません。これは、起動時に指定できるオプションが大雑把になるのが大きな理由の一つでした。シェル芸ではないですが、1行プログラミングだけで様々なことをするのは大変です。 そこで導入されたのがExtra Boot Configuration (bootconfig)です。Bootconfigについては前回の記事を参考にしてください。 ここではカーネルコマンドラインのトレースオプションと、Bootconfigによって拡張されたBoot-time trace（CON
Linuxカーネルをgdbでデバッグ（またはディストリビューションのカーネルを使うときは当たってるパッチにも注意しよう） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2018の1日目ですΣ(ﾟ∀ﾟﾉ)ﾉｷｬｰ イントロ ほんとは別の内容にしようと思ってたのですが、進めてる途中でカーネルのデバッグをするハメになったのでカーネルデバッグをネタにしてみました。カーネルのデバッグと言っても普通のデバッグと変わらないよね〜というところがわかると思います。（｀・ω・´)<ｺﾜｸﾅｲﾖｰ デバッグの環境としてはlibvirt(qemu)で動いてるゲスト環境にホスト側からgdbでデバッグする感じです。ディストリビューションはFedora 29です。デバッグするカーネルはFedoraのカーネルで4.19.2-300.fc29.x86_64です。 テストコード テストコードは↓です。これはdebugfsのディレクトリ（大概は/sys/kernel/debug/だと思います）にopen-testってファイルを作って、その
Linuxのsystem call fuzzer「syzkaller」めも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxのシステムコールのファジングツールとしてsyzkallerというのがあって、これはコードカバレッジを見つつ入力を変えていってくれるというファジングするツールです。 試してみたのでどんな感じなのかを簡単にめも。 まず、ツール自体はgolangで書かれているのでgoの実行環境が必要です。あとテスト対象のカーネル側でコードカバレッジを利用可能になっている必要があります。この辺はsyzkallerのドキュメントに書かれています。 ツールはビルドして行います。make一発で良いのですが、デフォルトだとstatic linkなバイナリを作ります。うちだと-lpthreadと-lcのところでそんなライブラリはないとか怒られてしまったので、動的リンクにしました。ホストとゲストのディストリビューションが同じならライブラリのABIの違いとかないですし、これで良いでしょう。 ファジングはVMを使って行
就職面接でプログラムの解読を求められた！ | POSTD
長文ですが、よかったら読んでください。 就職面接でプログラムの解読を求められました。そして、就職が決まりました。 皆さん、こんにちは。新しいブログを開設したので、私は今とても張り切っています。週に何度か記事を投稿するつもりです。 タイトルを見れば大体の話の内容は分かると思いますが、これから書くのは、トルコのアンカラで受けた就職面接の話です。 私が応募した職は「ソフトウェアセキュリティエンジニア」でした。面接中、面接官たちは非常に専門性が低い質問をしてきましたが、分かることもあれば分からないこともありました。 その後、その企業からメールが届き、保護および暗号化されたバイナリファイルが添付されていました（「解読してみろ」ということでしょう）。 帰宅後にファイルをダウンロードすると、ファイルを開くために聞かれたのはパスワードだけでした。面接官が私に課した課題は、そのパスワードを探すことでした。
シェルスクリプトのデバッグは typeset または declare を使うと良いかも - よんちゅBlog
はじめに つい最近知った便利なデバッグ方法 (長年シェルスクリプトを書いているのに知らなかった。これが常識だったら恥ずかしい…) シェルスクリプトのデバッグでは echo で変数の中身を見るという原始的な方法をよく使うかと思います。 いわゆる プリントデバッグ というやつですね。 もう少し詳しいデバッグが必要な場合は、 set -x と set +x でデバッグしたい部分を囲むという方法もあります。 今回は プリントデバッグ で使う echo の代わりに typeset or declare を使うと良いというお話です。 プリントデバッグは typeset or declare を使おう typeset or declare は変数宣言などでよく使うコマンドですが、変数の中身を見るのにも使えます。 echo と比べて何が良いのかというと、変数の中身はもちろん変数名や変数の型も表示してくれ、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
