> Nir Soffer wrote:
> > 
> > > > On a Linux machine, running Samba 2.2.4, we got this 
> error message:
> > > >
> > > > Aug  7 01:47:01 node1-mgmt winbindd[7034]: [2002/08/07 
> 01:47:01, 0]
> > > > rpc_client/cli_pipe.c:rpc_api_pipe(359)
> > > > Aug  7 01:47:01 node1-mgmt winbindd[7034]:   cli_pipe:
> > > return critical
> > > > error. Error was SUCCESS - 0
> > > >
> > > > Previous to that error message, winbindd ran without fault
> > > for nearly 30
> > > > days.
> > >
> > > The DC 'went away'.  (Which closed the pipe, and left 0 
> in the error
> > > feild - yes we need a better way do handle this...).
> > 
> > I guessed something to that effect, but I don't believe something
> > happened to the DC, that's what's bothering me. I'll need 
> to check that
> > out.
> > 
> > So if hit this DEBUG statement
> >  DEBUG(0, ("cli_pipe: return critical error. Error was %s\n",
> > cli_errstr(cli)));
> > 
> > When the error is 0 I should:
> > 
> > DEBUG(0, ("cli_pipe: Critical error - the pipe has closed. 
> The DC has
> > probably been disconnected") )
> > 
> > or something?
> > 
> > need a patch?
> 
> I'll take a patch that actually does the real job - that code needs to
> be 'upgraded' to NTSTATUS.  Follow the functions, and you will
> eventually get to 'cli_receive_smb()'.  This is what is generating the
> error - so it should probably get the DEBUG(), and a sensible NTSTATUS
> value should be returned down the chain.

Tracking down the code leads me at the end to receive_smb, which
probably returns a false when it fails to receive anything. But then
again, it could fail on anything, so nailing it down there seems wrong.

client_receive_smb appears to be merely a wrapper for receive_smb...

Ugh. This stuff is hairy. What exactly needs to happen? Does the code
have to see if there's BOTH an error from client_receive_smb, and if
there's no status set, and then conclude all it is is a broken link?

> It's really the BOOLs everywhere that causes the problem.

I haven't figured that one out yet -

A. What exactly _is_ the construct for keeping a status code, from
looking at clierrstr I see that there are 3 classes of error message,
each handled sepreately and differently (RAP messages, whatever the hell
they may be, NT STATUS messages, and DOS and SMB messages (?!) which are
apparently handled together? (?!?)

B. Why not return an int value that some meaning like most C functions
do?

Nir.


--
Nir Soffer -=- Software Engineer, Exanet Inc. -=-
"Father, why are all the children weeping? / They are merely crying son
 O, are they merely crying, father? / Yes, true weeping is yet to come"
        -- Nick Cave and the Bad Seeds, The Weeping Song
 

Reply via email to