[jcifs] Re: Disconnect from a share

Alexander Saupp asaupp at web.de
Mon Oct 17 15:20:41 GMT 2005

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) ( 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) ( 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?

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.

Thanks, Alex

More information about the jcifs mailing list