gripes with samba -- debug behavior

[Branko Cibej]

Marty Leisner wrote:

> I have to do some more work using samba to reverse
> engineer/confirm behavior of Micro$oft products...
>
> Ever since I was using samba (for the last 5 years), I hacked
> it up to:
>         Not daemonize and log to stdout.

I suppose an option to do that would be welcome, yes.

I've been doing things a bit differently. Put a delay loop in the code:

     if (stop_here)
     {
       int d = 1;
       while (d)
       {
          d = d; /*here*/
       }
     }

then attach to the process with the debugger, change the value of
d /*here*/ and continue. The reason for this is that mostly you want
to debug what's happening in the forked-off process that serves a
client (machine or smbclient), and it seemed easier to attach to the
process instead of starting Samba in the debugger; I've never been
particularly fond of debugging through a fork()...

I generally put this in two places:

     -- after the process turned daemon
     -- after the client's server was forked off.

I can't think of many more places where this would be useful, anything
else can be done with breakpoints in the debugger. I also didn't bother
redirecting logging to std{out,err}, although that might be useful.

> I just got the cvs version and looked at nmbd...
>
> (I'm happy the man page now mentions -D is not recommented).
>
> But the behavior:
>   if (!is_daemon && !is_a_socket(0))
>   {
>     DEBUG(0,("standard input is not a socket, assuming -D option\n"));
>     is_daemon = True;
>   }
>
> is pretty poor...

This is more or less necessary if you want to start Samba
via inetd, isn't it?

    Brane

--
Branko Čibej                 <branko.cibej at hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 61) 186 53 49   fax: (+386 61) 186 52 70