Better info, oops regarding ECONNRESET

[Green, Paul]

I suggest instrumenting the call(s) that Samba makes to read with a DEBUG
statement that is just like the TRUSS statement. The differences is that now
when you set up the DEBUGLEVEL value in Samba, you will get this new
pseudo-TRUSS output correctly mixed in with the usual Samba DEBUG
statements.  I have done this locally to try to track down some problems
with our POSIX runtime routines (still rather new).

I will send you my copy of system.c privately.

PG

-----Original Message-----

Date: Thu, 30 Aug 2001 12:07:11 -0400 (EDT)
From: Scott Moomaw <scott at bridgewater.edu>
To: <samba-technical at lists.samba.org>
Subject: Better info, oops regarding ECONNRESET

I found the RST packets coming from the host in question so you can
disregard my post from yesterday.  I wasn't looking far enough into the
output :-)  It's been a long week here . . .

Looking more carefully at the truss commands, I have some more info as to
the situation.  I'll include a truss snipped and then explain my theory.

19311:  open64("eudora/Out.mbx", O_RDWR|O_NONBLOCK)     = 23
19311:  gettimeofday(0x08253990)                        = 0
19311:  fcntl(13, F_SETLKW, 0x08046E9C)                 = 0
19311:  fcntl(13, F_SETLKW, 0x08046E9C)                 = 0
19311:  fcntl(13, F_SETLKW, 0x08047340)                 = 0
19311:  send(5, "\0\0\0 AFF S M B -\0\0\0".., 69, 0)    = 69
19311:  poll(0x08047884, 3, 60000)                      = 1
19311:  read(5, "\0\0\0 +", 4)                          = 4
19311:  read(5, "FF S M B12\0\0\0\0\0\0\0".., 43)       = 43
19311:  gettimeofday(0x081DF1C4)                        = 0
19311:  llseek(23, 0, SEEK_END)                         = 230402
19311:  send(5, "\0\0\0 'FF S M B12\0\0\0".., 43, 0)    = 43
19311:  poll(0x08047884, 3, 60000)                      = 1
19311:  read(5, "\0\0\0 3", 4)                          = 4
19311:  read(5, "FF S M B1A\0\0\0\0\0\0\0".., 51)       = 51
19311:  gettimeofday(0x081DF1C4)                        = 0
19311:  fstat64(23, 0x08047908)                         = 0
19311:  llseek(23, 230771, SEEK_SET)                    = 230771
19311:  read(23, 0x082222D5, -369)                      Err#22 EINVAL
19311:  write(5, "\001FF", 3)                           = 3
19311:  poll(0x08047884, 3, 60000)      (sleeping...)
19311:  poll(0x08047884, 3, 60000)                      = 1
19311:  read(5, 0x08211E89, 4)                          Err#131 ECONNRESET
19311:  time()                                          = 999186383
19311:  getuid()                                        = 0 [9023]

The client that I've truss'ed about is running Eudora and in the process
of sending a new message.  As part of this, it needs to append the new
message to Out.mbx on the server.  Looking at the Out.mbx that exists, I
find that it is exactly 230402 bytes in size.  If you look at the above
truss, you'll see a llseek to location 230771.  Then the process attempts
to read from a location 369 bytes prior.  The read(23, 0x082222D5, -369)
call fails with EINVAL because the read of negative bytes is disallowed.
It seems as if the system is trying to extend the file, by seeking beyond
its length, and then trying to backup using a negative read.  Make sense?

I think that this negative read is really where things start to breakdown.
Your thoughts, ideas, fixes are appreciated.

Scott
------------------------------------------------------------------------
 Scott Moomaw, Network Administrator              Scott at Bridgewater.edu
 Bridgewater College, IT Center
 Bridgewater, VA  22812
 Phone (540) 828 - 8000  x5437              FAX:  (540) 828 - 5493