smbd daemon mode

Andrew Bartlett abartlet at
Thu Dec 6 12:41:02 GMT 2001

Jochen Schneider wrote:
> > "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.
> describes a short workaround for the fork problem that is quite
> useful for smbd debugging.
> #
> #File:,  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.

Just for reference, this is how most developers handle it.  We don't
have any tricks up our sleave :-)  (Well, not too many...)

Andrew Bartlett

Andrew Bartlett                                 abartlet at
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at

More information about the samba-technical mailing list