[jcifs] Re: Disconnect from a share

[Michael B Allen]

On Mon, 17 Oct 2005 15:20:41 +0000 (UTC)
Alexander Saupp <asaupp at web.de> wrote:

> Michael B Allen <mba2000 <at> ioplex.com> writes:
> 
> >> I would be very interessted to have the Patch Michael proposed inside - 
> >> putting a 'new SmbComBlankResponse()' instead of null avoids that nasty
> >> errors Mathias mentioned.
> >> Any chance to get that fix into one of the next versions?
>  
> > No, because specifying a response causes the transport layer to wait
> > for it.
> 
> My point was that for my service checks (>50 servers every 30 seconds) I saw
> lots of the 'Broken Pipe' error messages Mathias mentioned earlier (see below). 
> 
>   [2005/10/17 17:06:46, 1] smbd/service.c:make_connection_snum(651)
>     9.155.83.62 (9.155.83.62) connect to service share initially as user 
>     de107563 (uid=1000, gid=100) (pid 7930)
>   [2005/10/17 17:06:48, 1] smbd/service.c:close_cnum(839)
>     9.155.83.62 (9.155.83.62) closed connection to service share
>   [2005/10/17 17:06:48, 0] lib/util_sock.c:write_socket_data(430)
>     write_socket_data: write failure. Error = Broken pipe
>   [2005/10/17 17:06:48, 0] lib/util_sock.c:write_socket(455)
>     write_socket: Error writing 43 bytes to socket 24: ERRNO = Broken pipe
>   [2005/10/17 17:06:48, 0] lib/util_sock.c:send_smb(647)
>     Error writing 43 bytes to client. -1. (Broken pipe)
> 
> I ran some more tests to reproduce the error in order to paste it here - and
> found that its connected to the variable "jcifs.smb.client.ssnLimit" which was
> set to 1. I removed that variable (going with the default now) - that seems to
> solve my issue (unless i see the error above again..)
> If there is a chance to get that massive amount of errors again - performance
> would still be more important than clean logs to you?

What versions of JCIFS and Samba are you using?

Also what is your smb.conf log level set to?

What other JCIFS properties are you setting?

One of the main issues with trying to resolve this issue was that I
could not reproduce the problem. Is there anything special about the
program you used to test the problem?

> One more question I would have for the experts: As this implementation is
> designed to be a service check - can i be sure that a new session with a fresh
> smbd is spawned at server side - and smb.conf is reread? I did some checks and
> it seems ok - but i would like to be absolutly sure about this point.

If JCIFS has an existing session with the desired domain and username
then probably not. It will simply reuse the existing session even with
jcifs.smb.client.ssnLimit=1. You would have to use different credentials
each time you query to ensure that a new transport is created.

Otherwise, if you are creating a fresh connection then I think smbd is
largely a fork(2) per socket type of server so probably yes but I don't
really know for sure. You would have to ask the samba-technical list.

Mike