smbd daemon mode

Jochen Schneider jochen.schneider at mediaways.net
Thu Dec 6 11:20:04 GMT 2001


> "Esh, Andrew" wrote:
> 
> I wish I didn't have to bother the list with this, but are there some
> special tricks to debugging smbd?
> 
> I see that the -D option puts smbd in daemon mode (which implies a
> fork), but not supplying the -D also puts it in daemon mode.
> Apparently, stdin has to be set up in some special way, because if it
> is not, smbd forces daemon mode.
> 
> I also tried to live with daemon mode, and use the gdb setting
> "follow-fork-mode". No matter what I set it to, it always follows the
> parent fork. I was able to get strace to stay with the code with the
> "-f" option, but strace follows both sides of the fork. gdb only
> follows ones side. I single step through "sys_fork", and I always wind
> up right away at "exit". I'm using "gdb 5.0rh-5 Red Hat Linux 7.1".
> smbd is dynamically linked, and not stripped. gdb steps through source
> code and prints variables right up to the point it exits, so the code
> has debug symbols.
> 
> Is there some tricky developer flag I have to flip somewhere to debug
> smbd, or did someone put drugs in my coffee? Which is more likely?
> 

Hi Andrew,
maybe I'm wrong, but I think follow-fork-mode is only available on
HP-UX.
gdb.info describes a short workaround for the fork problem that is quite
useful for smbd debugging.

#
#File: gdb.info,  Node: Processes,  Prev: Threads,  Up: Running
#
#Debugging programs with multiple processes
#==========================================
#
#   On most systems, GDB has no special support for debugging programs
#which create additional processes using the `fork' function.  When a
#program forks, GDB will continue to debug the parent process and the
#child process will run unimpeded.  If you have set a breakpoint in any
#code which the child then executes, the child will get a `SIGTRAP'
#signal which (unless it catches the signal) will cause it to terminate.
#
#   However, if you want to debug the child process there is a
workaround
#which isn't too painful.  Put a call to `sleep' in the code which the
#child process executes after the fork.  It may be useful to sleep only
#if a certain environment variable is set, or a certain file exists, so
#that the delay need not occur when you don't want to run GDB on the
#child.  While the child is sleeping, use the `ps' program to get its
#process ID.  Then tell GDB (a new invocation of GDB if you are also
#debugging the parent process) to attach to the child process (*note
#Attach::.).  From that point on you can debug the child process just
#like any other process which you attached to.
#
#   On HP-UX (11.x and later only?), GDB provides support for debugging
#programs that create additional processes using the `fork' or `vfork'
#function.
#
#   By default, when a program forks, GDB will continue to debug the
#parent process and the child process will run unimpeded.
#
#   If you want to follow the child process instead of the parent
#process, use the command `set follow-fork-mode'.
#...

If You use smbclient there is no need for a sleep() at all.
Smbd forks a child for the session and You can catch it's pid with
ps -e | grep smbd while the smbclient prompt is waiting for password
input.

Good luck,
 Jochen
-- 
          jochen.schneider at mediaways.net
   http://www.legasthenie-ist-keine-schande.de
<< Premature optimization is the root of all evil >>




More information about the samba-technical mailing list