On Mon, 26 Jun 2006, Stuart Whitby wrote:

SW> Well, the refusal to hit the inactivity timeout isn't a problem with 
SW> the inactivity timeout mechanism itself.  That works on when the save 
SW> last sent data to an mmd, so if no data has ever been sent the timeout 
SW> will never kick in.  As such that would be an RFE rather than a bug - 
SW> good luck getting that sorted out....

Heh, yeah, I wonder where all RFEs go to die.

SW> So if the save's created, what has it done after that point?  You'll 
SW> need to check this out with tcpview (www.sysinternals.com) or lsof 
SW> (www.sunfreeware.com or ftp.vic.cc.purdue.edu/pub/tools/unix/lsof) to 
SW> identify what connections have been made by save.  Ideally, if it's on 
SW> a Unix client, truss the save to see what it's trying to do.  This 
SW> should help identify where the problem exists.  Basic questions would 
SW> be whether the correct connection state exists on both sides of the 
SW> pipe (from save to the NW server/storage node) or whether that 
SW> connection had ever been attempted (tougher to find out).  If you can 
SW> get the same problem consistently from a client then you may be able 
SW> to wrapper the save process (if nsrexecd is happy to have a script as 
SW> a child) to run truss on the save, or netstatp (sysinternals) on a 
SW> very regular basis (once per second) for the first part of the save.

Yes, we're trying that path right now together with EMC support (maybe my 
nagging on this list has finally caught their attention? :) ), and we'll 
see what we can find. I'll keep the list posted if we do come up with 
something useful.

//Oscar

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER