From owner-freebsd-questions Thu Apr 10 07:02:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA06794 for questions-outgoing; Thu, 10 Apr 1997 07:02:03 -0700 (PDT) Received: from itsdsv1.enc.edu (itsdsv1.enc.edu [207.95.42.241]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA06789 for ; Thu, 10 Apr 1997 07:01:59 -0700 (PDT) Received: from dingo.its.enc.edu (dingo.its.enc.edu [207.95.222.250]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id KAA21290; Thu, 10 Apr 1997 10:04:51 -0400 (EDT) Date: Thu, 10 Apr 1997 10:09:41 -0400 (EDT) From: Charles Owens X-Sender: owensc@dingo.its.enc.edu To: Doug White cc: questions list FreeBSD Subject: Re: dump produces setsockopt error. Why? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 9 Apr 1997, Doug White wrote: > On Wed, 9 Apr 1997, Charles Owens wrote: > > > > > itsdsv3.enc.edu: Connection refused > > > > TCP_MAXSEG setsockopt: Bad file descriptor > > > > > > > > (itsdsv3 is the remote host, of course) > > > > > > > > Any ideas as to what's causing this? Both hosts are running 2.1-stable > > > > (just slightly pre-2.1.5-RELEASE... yes, I know, I need to upgrade). > > > > > > You need to tell itsdsv3 to accept rsh connections. > > > > This is true, but I've already done this. On itsdsv3 I have a dummy user > > set up that has write permission to the tape drive device. In this dummy > > user's home dir I have a .rhost file with entries of the sort: > > [ user info ] > > Looks OK... > > > I have these dumps being invoked from a script. The script does this: > > > > 1. uses mt to rewind remote tape > > 2. uses mt to possibly skip forward x number of file marks > > 3. invokes dump several times to backup various local file systems > > > > Until recently, it worked fine, every time. Lately, however, I've been > > getting a "connection refused" error with step 2 or with the first dump > > invocation in step 3. If the latter, then the first partition dump is > > aborted but _all_other_ dumps complete without error!!! > > I wonder if you are hitting one of the minor problems that sometimes rears > up with rsh. We've had trouble in the past (2.1.x series) with rsh not > responding to connections for 30s after the last one has closed. You > might try sticking a 'sleep 30' between the commands, just to make sure > everything has settled before continuing to the next step. > > Doug White | University of Oregon > Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant > http://gladstone.uoregon.edu/~dwhite | Computer Science Major Ah-ha! At some point I had stuck in five second delays, which I thought had helped... but 30 seconds seemed to do the trick. Thanks very much!!! --- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Network & Systems Administrator Information Technology Services "Outside of a dog, a book is a man's Eastern Nazarene College best friend. Inside of a dog it's too dark to read." - Groucho Marx -------------------------------------------------------------------------