gripes with samba -- debug behavior

[Cole, Timothy D.]

> -----Original Message-----
> From:	Branko Cibej [SMTP:branko.cibej at hermes.si]
> Sent:	Tuesday, August 17, 1999 10:32
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	Re: gripes with samba -- debug behavior
> 
> 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()...
> 
Why not just raise a SIGSTOP, rather than busy-waiting?

> 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?
> 
	Isn't that usage depreciated anyway, though?