Chapter 40. バグの報告

John H. Terpstra

Samba Team

Jelmer R. Vernooij

The Samba Team

Andrew Tridgell

Samba Team

27 June 1997

Table of Contents

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

概要

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.machineとして作成する。例えば、log levelは便利に使えるだろう。これはまた、異なったセキュリティシステム、プロトコルレベルなどを1つのマシン上で体験することもできる。

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 level0という最初の値は、特定の機能単位に対するデバッグクラスを 除き、すべての不必要なデバッグ出力を抑止する。 デバッグ単位の表は、Sambaが処理している各SMB 操作をとても正確に分析するのに使うことが出来るかもしれない。

Table 40.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オプションを付けてコンパイルすると、シンボルが埋め込まれる。以下の行を、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を取るようにすることと、正確にどのバージョンを使用しているかを知らせてほしい。