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

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

もしも、comp.protocols.smbニュースグループか、メーリングリストに投稿した 場合、それを開発者が読むと思ってはいけない。もしも、問題がバグではなくて、 設定の問題だと推測したならば、手助けできる人がたくさんいるSambaメーリング リストに送った方がよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

$ gdb smbd core

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

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

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

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

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

panic action = "/bin/sleep 90000"

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

root#  gdb /usr/local/samba/sbin/smbd

次に、“attach `pid'”(pidは空回りしているプロセス)を行い、次に コールパス中のどこにsmbdがいるかを見るために“bt”を入力して バックトレースを取る。

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