Chapter 37. バグの報告

27 June 1997

Table of Contents

概要
一般的な情報
デバッグレベル
デバッグ固有の操作
内部エラー
稼働中のプロセスへのアタッチ
パッチ

概要

SambaのBugzilla機能を使って バグを報告し、また、報告を投稿する前に、この章を読んでほしい。また、 もしも、リリース間での変更があるかと、同様にある時点でバグ報告機能を 変更したかもしれないことを調べてほしい。

自分自身で出来るだけバグを追い詰めてほしい。Sambaは、ボランティアで時間、技術、労力を 提供している自主的なグループによって保守されている。問い合わせに対応しきれないメールを 受け取っているので、早く修正できる形で、開発者にわかりやすいバグ報告を 送ってもらえると、返事とバグ修正の機会が大きくなる。

もしも、問題がバグではなくて、 設定の問題だと推測したならば、手助けできる人がたくさんいるSambaメーリング リストに送った方がよい。

http://samba.org/samba/の、 Samba Webページ上で便利にアクセスできる、最近のメーリングリストアーカイブを見る事を 好むかもしれない。

一般的な情報

バグレポートを投稿する前に、エラーに対する設定を確認する。設定を間違えていると いう明確なメッセージをログファイルの中でサポートする。正しい文法になっているか、 設定ファイルをtestparmでチェックする。

Sambaチェックリストを見てみたか?これはとても 重要である。

もしも、バグレポートの中にログファイルを含めるならば、その時点でクライアント上で 何をしたかということを正確に、その結果が何であるかを正確に注釈を付けること。

デバッグレベル

もしも、バグが、サーバーとしてSambaの正しくない動作を何かしているならば (例えばファイルのオープンを断るなど)、ログファイルがとても便利に使えるだろう。 現象にもよるが、ログレベル3から10の間が、適切に問題を表示するかもしれない。 より大きなレベルはより詳細な結果が得られるが、とてもたくさんのディスクを 消費する。

debug levelを設定するには、中でlog levelを指定する。 また、特定のマシンだけログレベルを大きくし、各マシン毎に分離すると便利である。 これを行うには、中に以下の行を追加する:

log level = 10
log file = /usr/local/samba/lib/log.%m
include = /usr/local/samba/lib/smb.conf.%m

かつ、希望するコマンドを含むを、新たに /usr/local/samba/lib/smb.conf.machineとして 作成する。例えば、log levelは便利に使えるだろう。 これはまた、異なったセキュリティシステム、プロトコルレベルなどを1つのマシン上で 体験することもできる。

のエントリlog levelは、古いバージョンのSambaで 使われていたパラメーターdebuglevelと同義語であり、 ファイルの下位互換性のためにそのまま残っている。

log levelの値を大きくすると、きわめて大量のデバッグ情報を 記録することになる。多くのデバッグ作業において、この値を3より 大きくする必要はないだろう。値を10にすると、ほとんどすべての バグが記録されるが、大きなログデータ領域を準備する必要がある。

デバッグ固有の操作

Samba-3.xはすべての操作に対する詳細なログが書かれるログファイル中で、 必要のない項目を外して特定の機能コンポーネントだけをデバッグ(ロギング)する ことができる。これを行うための設定例は以下の通り:

log level = 0 tdb:3 passdb:5 auth:4 vfs:2
max log size = 0
log file = /var/log/samba/%U.%m.log

これは、上記で示されている値毎に各機能単位にデバッグクラス(ログレベル)を 渡すために詳細なレベルを拡張している。log level0という最初の値は、特定の機能単位に対するデバッグクラスを 除き、すべての不必要なデバッグ出力を抑止する。 デバッグ単位の表は、Sambaが処理している各SMB 操作をとても正確に分析するのに使うことが出来るかもしれない。

Table 37.1. デバッグ単位

機能名機能名
allpassdb
tdbsam
printdriversauth
lanmanwinbind
smbvfs
rpc_parseidmap
rpc_srvquota
rpc_cliacls

内部エラー

もしも、ログファイル中に、INTERNAL ERRORという メッセージがあったら、これはSambaが動作中に予期しないシグナルを受け取ったことを意味する。 これはおそらくセグメンテーションフォルトで、多くの場合Sambaのバグである(ハードウェア の故障かシステムソフトゥエアのバグを除く)。

メッセージがsmbd由来であれば、smbが受け取った最後のSMBメッセージを詳細に説明する メッセージがおそらくあるだろう。この情報は、問題を解析するのにしばしば便利であるので、 バグレポートの中に一緒に入れてほしい。

もしも可能ならば、どのように問題を再現するかについての詳細も説明してほしい。 適度に詳細を記述してほしい。

Sambaログファイルが保存されているディレクトリのcorefilesサブ ディレクトリにコアファイルが存在する場合があるかもしれない。このファイルは、 バグを追跡するのに最も便利なものである。これを利用するには以下のようにする:

gdb smbd core

smbdとcoreに対する適切なパスを追加すると、gdbはそれらを扱えることが出来る。 もしもgdbを用意していないならば、dbxを試してみること。 デバッガー内でwhereコマンドを使うと、どこで問題が発生したかの トレースが得られる。これをレポートに含める。

もしも、何らかのアセンブラ言語について知っているならば、どこで問題が発生したか を(もしもそれがライブラリルーチン内ならば、それを呼び出しているルーチンを 逆アセンブルする)、disassで逆アセンブルし、そのコードの周辺を 調べることで、正確にどこで現象が起きたかを調べてみる。アセンブラ言語について 知らなくても、逆アセンブル結果をバグレポートに含めることは解析に役に立つ。

稼働中のプロセスへのアタッチ

不幸にも、いくつかのUNIX(特に最近のLinuxカーネルのいくつか)は、タスクがUIDを 変えたとき(smbdはしばしばこれを行う)コアファイルの作成を抑制する。 このような種類のシステムでデバッグするには、まず、 smbstatusPIDを得、 次に、gdb smbd PID を使って、稼働中のプロセスにアタッチしてみる。次に、c を使って処理を続行し、クライアントを使ってコアダンプを起こさせる。 デバッガーはフォルトを受け取り、どこでそれが起こったかを表示する。

時には、Samba Teamに問題を修正してもらうために、クラッシュした操作からの十分な情報を キャプチャすることを可能とさせるために、デバッグシンボルを持つSambaバイナリファイルを 構築する必要がある。

-gオプションを付けてコンパイルすると、シンボルが埋め込まれる。 以下の行を、ファイルのグローバルセクションに追加する:

panic action = "/bin/sleep 90000"

これにより任意のパニックをキャッチできる。もしも、smbdが 固まってしまったように見えたら、sleepしているプロセスを捜す。もしも存在せず、 空回りしてるように見えたら、空回りしているように見えるプロセスのPIDを調べ、 以下のように入力する:

 gdb -p PID

次に、コールパス中のどこにsmbdがいるかを見るためにbtを入力して バックトレースを取る。

パッチ

最も良い形のバグレポートは、修正を含むものである!もしも、パッチを送って もらえるのであれば、使用しているdiffがサポートしているのであれば、 diff -uで差分を取ってほしい。そうでない場合、 diff -c4を使ってほしい。オリジナルのソースに対する diffを取るようにすることと、正確にどのバージョンを使用しているかを知らせて ほしい。