From owner-freebsd-questions Wed Apr 9 11:26:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA06326 for questions-outgoing; Wed, 9 Apr 1997 11:26:27 -0700 (PDT) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA06317 for ; Wed, 9 Apr 1997 11:26:19 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id LAA04226; Wed, 9 Apr 1997 11:26:08 -0700 (PDT) Date: Wed, 9 Apr 1997 11:26:08 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Charles Owens 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, 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