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
中に以下の行を追加する:
log level = 10 |
log file = /usr/local/samba/lib/log.%m |
include = /usr/local/samba/lib/smb.conf.%m |
かつ、希望するコマンドを含むsmb.conf
を、新たに/usr/local/samba/lib/smb.conf.
として作成する。例えば、log levelは便利に使えるだろう。これはまた、異なったセキュリティシステム、プロトコルレベルなどを1つのマシン上で体験することもできる。machine
smb.conf
のエントリlog levelは、古いバージョンのSambaで使われていたパラメータdebuglevelと同義語であり、smb.conf
ファイルの下位互換性のためにそのまま残っている。
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 level
の 0
という最初の値は、特定の機能単位に対するデバッグクラスを 除き、すべての不必要なデバッグ出力を抑止する。 デバッグ単位の表は、Sambaが処理している各SMB 操作をとても正確に分析するのに使うことが出来るかもしれない。
Table 40.1. デバッグ単位
機能名 | 機能名 |
---|---|
all | passdb |
tdb | sam |
printdrivers | auth |
lanman | winbind |
smb | vfs |
rpc_parse | idmap |
rpc_srv | quota |
rpc_cli | acls |
もしも、ログファイル中に、“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”を入力してバックトレースを取る。