svn commit: samba-docs r711 - in trunk/Samba3-HOWTO: .

jht at samba.org jht at samba.org
Tue Jun 28 21:41:48 GMT 2005


Author: jht
Date: 2005-06-28 21:41:48 +0000 (Tue, 28 Jun 2005)
New Revision: 711

WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba-docs&rev=711

Log:
Update.
Modified:
   trunk/Samba3-HOWTO/TOSHARG-Bugs.xml


Changeset:
Modified: trunk/Samba3-HOWTO/TOSHARG-Bugs.xml
===================================================================
--- trunk/Samba3-HOWTO/TOSHARG-Bugs.xml	2005-06-28 21:23:26 UTC (rev 710)
+++ trunk/Samba3-HOWTO/TOSHARG-Bugs.xml	2005-06-28 21:41:48 UTC (rev 711)
@@ -14,11 +14,12 @@
 <sect1>
 <title>Introduction</title>
 
-<para>Please report bugs using Samba's
-<ulink url="https://bugzilla.samba.org/">Bugzilla</ulink> facilities and
-take the time to read this file before you submit a bug
-report. Also, check to see if it has changed between releases, as we
-may be changing the bug reporting mechanism at some point.
+<para>
+<indexterm><primary>Bugzilla</primary></indexterm>
+<indexterm><primary>bug reports</primary></indexterm>
+Please report bugs using Samba's <ulink url="https://bugzilla.samba.org/">Bugzilla</ulink> facilities and take
+the time to read this file before you submit a bug report. Also, check to see if it has changed between
+releases, as we may be changing the bug reporting mechanism at some point.
 </para>
 
 <para>
@@ -31,6 +32,9 @@
 </para>
 
 <para>
+<indexterm><primary>comp.protocols.smb</primary></indexterm>
+<indexterm><primary>newsgroup</primary></indexterm>
+<indexterm><primary>configuration problem</primary></indexterm>
 If you post the bug to the comp.protocols.smb
 newsgroup or the mailing list, do not assume that we will read it. If you suspect that your 
 problem is not a bug but a configuration problem, it is better to send 
@@ -80,40 +84,37 @@
 </para>
 
 <para>
+<indexterm><primary>debug level</primary></indexterm>
+<indexterm><primary>log level</primary></indexterm>
 To set the debug level, use the <smbconfoption name="log level"/> in your 
 &smb.conf;. You may also find it useful to set the log 
 level higher for just one machine and keep separate logs for each machine. 
 To do this, add the following lines to your main &smb.conf; file:
 </para>
 
-<para><smbconfblock>
+<smbconfblock>
 <smbconfoption name="log level">10</smbconfoption>
 <smbconfoption name="log file">/usr/local/samba/lib/log.%m</smbconfoption>
 <smbconfoption name="include">/usr/local/samba/lib/smb.conf.%m</smbconfoption>
-</smbconfblock></para>
+</smbconfblock>
 
 <para>
 and create a file <filename>/usr/local/samba/lib/smb.conf.<replaceable>machine</replaceable></filename> where
-<replaceable>machine</replaceable> is the name of the client you wish to debug. In that file
-put any &smb.conf; commands you want; for example, 
-<smbconfoption name="log level"/> may be useful. This also allows you to 
-experiment with different security systems, protocol levels, and so on, on just 
-one machine.
+<replaceable>machine</replaceable> is the name of the client you wish to debug. In that file put any
+&smb.conf; commands you want; for example, <smbconfoption name="log level"/> may be useful. This also allows
+you to experiment with different security systems, protocol levels, and so on, on just one machine.
 </para>
 
 <para>
-The &smb.conf; entry <smbconfoption name="log level"/> 
-is synonymous with the parameter <smbconfoption name="debuglevel"/> that has
-been used in older versions of Samba and is being retained for backward 
+The &smb.conf; entry <smbconfoption name="log level"/> is synonymous with the parameter <smbconfoption
+name="debuglevel"/> that has been used in older versions of Samba and is being retained for backward
 compatibility of &smb.conf; files.
 </para>
 
 <para>
-As the <smbconfoption name="log level"/> value is increased, you will record 
-a significantly greater level of debugging information. For most 
-debugging operations, you may not need a setting higher than 
-<constant>3</constant>. Nearly 
-all bugs can be tracked at a setting of <constant>10</constant>, but be 
+As the <smbconfoption name="log level"/> value is increased, you will record a significantly greater level of
+debugging information. For most debugging operations, you may not need a setting higher than
+<constant>3</constant>. Nearly all bugs can be tracked at a setting of <constant>10</constant>, but be
 prepared for a large volume of log data.
 </para>
 
@@ -121,6 +122,10 @@
 	<title>Debugging-Specific Operations</title>
 
 	<para>
+<indexterm><primary>debugging</primary></indexterm>
+<indexterm><primary>logging</primary></indexterm>
+<indexterm><primary>functional components</primary></indexterm>
+<indexterm><primary>cluttering</primary></indexterm>
 	Samba-3.x permits debugging (logging) of specific functional components without unnecessarily
 	cluttering the log files with detailed logs for all operations. An example configuration to 
 	achieve this is shown in:
@@ -196,14 +201,14 @@
 use it, you do this:
 <indexterm><primary>gdb</primary></indexterm>
 <indexterm><primary>debug</primary></indexterm>
-</para>
-
-
 <screen>
 &prompt;<userinput>gdb smbd core</userinput>
 </screen>
+</para>
 
 <para>
+<indexterm><primary>dbx</primary></indexterm>
+<indexterm><primary>stack trace</primary></indexterm>
 adding appropriate paths to smbd and core so gdb can find them. If you
 do not have gdb, try <userinput>dbx</userinput>. Then within the debugger,
 use the command <command>where</command> to give a stack trace of where the
@@ -211,6 +216,7 @@
 </para>
 
 <para>
+<indexterm><primary>disass</primary></indexterm>
 If you know any assembly language, do a <command>disass</command> of the routine
 where the problem occurred (if it's in a library routine, then
 disassemble the routine that called it) and try to work out exactly
@@ -224,6 +230,9 @@
 <title>Attaching to a Running Process</title>
 
 <para>
+<indexterm><primary>PID</primary></indexterm>
+<indexterm><primary>gdb</primary></indexterm>
+<indexterm><primary>smbstatus</primary></indexterm>
 Unfortunately, some UNIXes (in particular some recent Linux kernels)
 refuse to dump a core file if the task has changed UID (which smbd
 does often). To debug with this sort of system, you could try to attach
@@ -251,8 +260,9 @@
 processes. If it is not, and appears to be spinning, find the PID
 of the spinning process and type:
 <screen>
-gdb /usr/local/samba/sbin/smbd
+&rootprompt; gdb /usr/local/samba/sbin/smbd
 </screen>
+<indexterm><primary>spinning process</primary></indexterm>
 then <quote>attach `pid'</quote> (of the spinning process), then type <quote>bt</quote> to
 get a backtrace to see where the smbd is in the call path.
 </para>



More information about the samba-cvs mailing list