[jcifs] Re: Disconnect from a share
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)
22.214.171.124 (126.96.36.199) 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)
188.8.131.52 (184.108.40.206) 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.
More information about the jcifs