From owner-ctm-users@FreeBSD.ORG Thu Apr 22 11:49:54 2004 Return-Path: Delivered-To: ctm-users@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB3F116A4CE for ; Thu, 22 Apr 2004 11:49:54 -0700 (PDT) Received: from sep.oldach.net (sep.oldach.net [194.180.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id C415543D58 for ; Thu, 22 Apr 2004 11:49:53 -0700 (PDT) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1])i3MIne9O036886 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2004 20:49:43 +0200 (CEST) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.12.11/8.12.11/Submit) id i3MIncre036885; Thu, 22 Apr 2004 20:49:38 +0200 (CEST) (envelope-from hmo) Message-Id: <200404221849.i3MIncre036885@sep.oldach.net> In-Reply-To: <40880AB5.7020108@math.missouri.edu> from Stephen Montgomery-Smith at "Apr 22, 2004 1:11: 1 pm" To: stephen@math.missouri.edu (Stephen Montgomery-Smith) Date: Thu, 22 Apr 2004 20:49:38 +0200 (CEST) From: Helge Oldach X-Message-Flag: No HTML mail please MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sep.oldach.net cc: ctm-users@freebsd.org Subject: Re: CTM broke - last available Delta was April 19, please fix ASAP X-BeenThere: ctm-users@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CTM User discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 18:49:55 -0000 Stephen Montgomery-Smith: > I think I found the problem with the ftp sites for the CTM deltas. Recently was > created a new xEmpty for cvs-cur. It seems that rsync takes more than an hour > to download this file, by which time a new rsync daemon starts. The effect > seems to be that the older rsync process simply stops (although it does not get > killed), and the new rsync process starts all over again. > > A fix to this problem is to reduce the number of times that the rsync update > takes place. But really this seems to be a problem with rsync. Any other > suggestions? Why do you start a new daemon at all? I am using rsync for copying snapshots of running jails to another box, and never found the need to restart rsyncd. If you restart with /usr/local/etc/rc.d/rsyncd.sh stop && /usr/local/etc/rc.d/rsyncd.sh start the rc.subr script should hang until the first rsyncd has finished its transfers. Helge