summaryrefslogtreecommitdiff
path: root/docs/htmldocs/Bugs.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/Bugs.html')
-rw-r--r--docs/htmldocs/Bugs.html238
1 files changed, 0 insertions, 238 deletions
diff --git a/docs/htmldocs/Bugs.html b/docs/htmldocs/Bugs.html
deleted file mode 100644
index 0f7fb7bd60..0000000000
--- a/docs/htmldocs/Bugs.html
+++ /dev/null
@@ -1,238 +0,0 @@
-<HTML
-><HEAD
-><TITLE
->Reporting Bugs</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
-><BODY
-CLASS="ARTICLE"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="ARTICLE"
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
-><A
-NAME="BUGREPORT"
->Reporting Bugs</A
-></H1
-><HR></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN3"
->Introduction</A
-></H1
-><P
->The email address for bug reports is samba@samba.org</P
-><P
->Please take the time to read this file before you submit a bug
-report. Also, please see if it has changed between releases, as we
-may be changing the bug reporting mechanism at some time.</P
-><P
->Please also do as much as you can yourself to help track down the
-bug. Samba is maintained by a dedicated group of people who volunteer
-their time, skills and efforts. We receive far more mail about it than
-we can possibly answer, so you have a much higher chance of an answer
-and a fix if you send us a "developer friendly" bug report that lets
-us fix it fast. </P
-><P
->Do not assume that if you post the bug to the comp.protocols.smb
-newsgroup or the mailing list that we will read it. If you suspect that your
-problem is not a bug but a configuration problem then it is better to send
-it to the Samba mailing list, as there are (at last count) 5000 other users on
-that list that may be able to help you.</P
-><P
->You may also like to look though the recent mailing list archives,
-which are conveniently accessible on the Samba web pages
-at http://samba.org/samba/ </P
-></DIV
-><DIV
-CLASS="SECT1"
-><HR><H1
-CLASS="SECT1"
-><A
-NAME="AEN10"
->General info</A
-></H1
-><P
->Before submitting a bug report check your config for silly
-errors. Look in your log files for obvious messages that tell you that
-you've misconfigured something and run testparm to test your config
-file for correct syntax.</P
-><P
->Have you run through the <A
-HREF="Diagnosis.html"
-TARGET="_top"
->diagnosis</A
->?
-This is very important.</P
-><P
->If you include part of a log file with your bug report then be sure to
-annotate it with exactly what you were doing on the client at the
-time, and exactly what the results were.</P
-></DIV
-><DIV
-CLASS="SECT1"
-><HR><H1
-CLASS="SECT1"
-><A
-NAME="AEN16"
->Debug levels</A
-></H1
-><P
->If the bug has anything to do with Samba behaving incorrectly as a
-server (like refusing to open a file) then the log files will probably
-be very useful. Depending on the problem a log level of between 3 and
-10 showing the problem may be appropriate. A higher level givesmore
-detail, but may use too much disk space.</P
-><P
->To set the debug level use <B
-CLASS="COMMAND"
->log level =</B
-> in your
-<TT
-CLASS="FILENAME"
->smb.conf</TT
->. 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 use:</P
-><P
-><PRE
-CLASS="PROGRAMLISTING"
->log level = 10
-log file = /usr/local/samba/lib/log.%m
-include = /usr/local/samba/lib/smb.conf.%m</PRE
-></P
-><P
->then create a file
-<TT
-CLASS="FILENAME"
->/usr/local/samba/lib/smb.conf.machine</TT
-> where
-"machine" is the name of the client you wish to debug. In that file
-put any smb.conf commands you want, for example
-<B
-CLASS="COMMAND"
->log level=</B
-> may be useful. This also allows you to
-experiment with different security systems, protocol levels etc on just
-one machine.</P
-><P
->The <TT
-CLASS="FILENAME"
->smb.conf</TT
-> entry <B
-CLASS="COMMAND"
->log level =</B
->
-is synonymous with the entry <B
-CLASS="COMMAND"
->debuglevel =</B
-> that has been
-used in older versions of Samba and is being retained for backwards
-compatibility of smb.conf files.</P
-><P
->As the <B
-CLASS="COMMAND"
->log level =</B
-> value is increased you will record
-a significantly increasing level of debugging information. For most
-debugging operations you may not need a setting higher than 3. Nearly
-all bugs can be tracked at a setting of 10, but be prepared for a VERY
-large volume of log data.</P
-></DIV
-><DIV
-CLASS="SECT1"
-><HR><H1
-CLASS="SECT1"
-><A
-NAME="AEN33"
->Internal errors</A
-></H1
-><P
->If you get a "INTERNAL ERROR" message in your log files it means that
-Samba got an unexpected signal while running. It is probably a
-segmentation fault and almost certainly means a bug in Samba (unless
-you have faulty hardware or system software)</P
-><P
->If the message came from smbd then it will probably be accompanied by
-a message which details the last SMB message received by smbd. This
-info is often very useful in tracking down the problem so please
-include it in your bug report.</P
-><P
->You should also detail how to reproduce the problem, if
-possible. Please make this reasonably detailed.</P
-><P
->You may also find that a core file appeared in a "corefiles"
-subdirectory of the directory where you keep your samba log
-files. This file is the most useful tool for tracking down the bug. To
-use it you do this:</P
-><P
-><B
-CLASS="COMMAND"
->gdb smbd core</B
-></P
-><P
->adding appropriate paths to smbd and core so gdb can find them. If you
-don't have gdb then try "dbx". Then within the debugger use the
-command "where" to give a stack trace of where the problem
-occurred. Include this in your mail.</P
-><P
->If you known any assembly language then do a "disass" of the routine
-where the problem occurred (if its in a library routine then
-disassemble the routine that called it) and try to work out exactly
-where the problem is by looking at the surrounding code. Even if you
-don't know assembly then incuding this info in the bug report can be
-useful. </P
-></DIV
-><DIV
-CLASS="SECT1"
-><HR><H1
-CLASS="SECT1"
-><A
-NAME="AEN43"
->Attaching to a running process</A
-></H1
-><P
->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
-to the running process using "gdb smbd PID" where you get PID from
-smbstatus. Then use "c" to continue and try to cause the core dump
-using the client. The debugger should catch the fault and tell you
-where it occurred.</P
-></DIV
-><DIV
-CLASS="SECT1"
-><HR><H1
-CLASS="SECT1"
-><A
-NAME="AEN46"
->Patches</A
-></H1
-><P
->The best sort of bug report is one that includes a fix! If you send us
-patches please use <B
-CLASS="COMMAND"
->diff -u</B
-> format if your version of
-diff supports it, otherwise use <B
-CLASS="COMMAND"
->diff -c4</B
->. Make sure
-your do the diff against a clean version of the source and let me know
-exactly what version you used. </P
-></DIV
-></DIV
-></BODY
-></HTML
-> \ No newline at end of file