From owner-freebsd-ports@FreeBSD.ORG Sat Aug 11 13:35:50 2012
Return-Path: <owner-freebsd-ports@FreeBSD.ORG>
Delivered-To: ports@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id DFA5710656F2;
Sat, 11 Aug 2012 13:35:49 +0000 (UTC)
(envelope-from michael@ranner.eu)
Received: from mail.azedo.at (mail.azedo.at [91.118.6.139])
by mx1.freebsd.org (Postfix) with ESMTP id 2C9DF8FC0C;
Sat, 11 Aug 2012 13:35:48 +0000 (UTC)
Received: from mail.azedo.at (dovecot.azedo.at [172.20.10.3])
by mail.azedo.at (Postfix) with ESMTP id 4FADCA6C157;
Sat, 11 Aug 2012 15:35:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at azedo.at
Received: from mail.azedo.at ([172.20.10.3])
by mail.azedo.at (mail.azedo.at [172.20.10.3]) (amavisd-new, port 10024)
with ESMTP id UQighMNrXV72; Sat, 11 Aug 2012 15:35:34 +0200 (CEST)
Received: from lynx.ranner.eu (chello084115144217.4.graz.surfer.at
[84.115.144.217])
by mail.azedo.at (Postfix) with ESMTPSA id 2155FA6C14C;
Sat, 11 Aug 2012 15:35:34 +0200 (CEST)
Message-ID: <50265FA4.6020405@ranner.eu>
Date: Sat, 11 Aug 2012 15:35:32 +0200
From: Michael Ranner <michael@ranner.eu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Doug Barton <dougb@FreeBSD.org>
References: <50250E97.4000004@ranner.eu>
<CAA96eVsYX1TaXkFg4tXV=KXhbc6wE8ZhhfWi8RUzEjKwGCEtfQ@mail.gmail.com>
<502523D4.4050200@ranner.eu>
<CAA96eVu8vs3cLRxUacW2Qu9K6iBdNbydBrhH4NUO1hqAWo7nfA@mail.gmail.com>
<50258D15.8010606@FreeBSD.org>
<CAA96eVuVdFGiiZZmryPN=eu0=mnT-VNsdG_j1UsPToNi48ZSfQ@mail.gmail.com>
<5025B03A.5080707@FreeBSD.org> <50261211.3090502@ranner.eu>
<5026133B.5000500@FreeBSD.org> <502616A8.5010200@ranner.eu>
<50262406.2000302@FreeBSD.org>
In-Reply-To: <50262406.2000302@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: ports@freebsd.org, HU Dong <itechbear@gmail.com>
Subject: Re: portmaster 3.13.13 real endless loop "Waiting on fetch &
checksum..."
X-BeenThere: freebsd-ports@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting software to FreeBSD <freebsd-ports.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
<mailto:freebsd-ports-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ports>
List-Post: <mailto:freebsd-ports@freebsd.org>
List-Help: <mailto:freebsd-ports-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
<mailto:freebsd-ports-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Aug 2012 13:35:50 -0000
Ok, I have debugged the subshell:
I replaced the pm_make for "make -DBATCH checksum" with an pm_make2
function:
...
pm_make2 () { ( unset -v CUR_DEPS INSTALLED_LIST PM_DEPTH build_l
PM_URB_LIST;
echo "XXX5" >/tmp/xxx5
pwd >>/tmp/xxx5
echo "/usr/bin/nice /usr/bin/make $PM_MAKE_ARGS $*" >>/tmp/xxx5
/usr/bin/nice /usr/bin/make $PM_MAKE_ARGS $*; echo "XXX6"
>/tmp/xxx6 ); }
...
echo "XXX1" >/tmp/xxx1
(echo "XXX2" >/tmp/xxx2; pm_make2 -DBATCH checksum >>
$fetchlog 2>&1 && echo "XXX3" >/tmp/xxx3 && {
echo "XXX4" >/tmp/xxx4
rm -f ${TMPDIR}/f-${PM_PARENT_PID}-*-${portdir#*/}.*;
exit 0; }
allfiles=`pm_make -V ALLFILES`
pm_make delete-distfiles RESTRICTED_FILES="${allfiles}" \
>> $fetchlog 2>&1 &&
echo "===>>> RE-STARTING FETCH <<<===" >> $fetchlog
pm_make -DBATCH checksum >> $fetchlog 2>&1
rm -f ${TMPDIR}/f-${PM_PARENT_PID}-*-${portdir#*/}.* )&
...
It hangs on /usr/bin/nice /usr/bin/make $PM_MAKE_ARGS $*;
I will get no XXX6 output and there is no nice, make or fetch process.
There seems some weird problem with "-DBATCH" on my system. With the
following modification (without -DBATCH) fetch will start to download
but it will still not exit from pm_make2. There is no output for XXX6
pm_make2 () { ( unset -v CUR_DEPS INSTALLED_LIST PM_DEPTH build_l
PM_URB_LIST;
echo "XXX5" >/tmp/xxx5
pwd >>/tmp/xxx5
echo "/usr/bin/nice /usr/bin/make $PM_MAKE_ARGS $*" >>/tmp/xxx5
/usr/bin/make checksum >/tmp/xxx6 2>&1
#/usr/bin/nice /usr/bin/make $PM_MAKE_ARGS $*; echo "XXX6"
>>/tmp/xxx6 ); }
/usr/bin/nice /usr/bin/make checksum; echo "XXX6" >>/tmp/xxx6 ); }
But make -DBATCH checksum works from commandline:
[root@gatekeeper /usr/ports/archivers/unzip]# make -DBATCH checksum
===> License Info-ZIP accepted by the user
Use INSTALL_AS_INFOUNZIP=yes to install Info Unzip as
/usr/local/bin/info-unzip
=> unzip60.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch
http://surfnet.dl.sourceforge.net/project/infozip/UnZip%206.x%20%28latest%29/UnZip%206.0/unzip60.tar.gz
unzip60.tar.gz 100% of 1344 kB 125 kBps
00m00s
=> SHA256 Checksum OK for unzip60.tar.gz.
Any idea?
Am 11.08.12 11:21, schrieb Doug Barton:
> On 08/11/2012 01:24 AM, Michael Ranner wrote:
>> As I already told, "portmaster -F" is fetching to /usr/ports/distfiles
>> and appending to fetchlog in /tmp
> In your other message you indicate that the fetchlog in /tmp is empty.
> So I'm confused.
>
>> But "portmaster -i" does this not!
> By the time it gets to the 'make checksum' process there is nothing
> different about the code for -F or -i.
>
> Based on what you're describing it sounds like your fetch process is
> hanging, and/or not exiting properly.
>
> What portmaster does is launch a subshell in the background that has a
> mini-script to run 'make checksum'. That target will verify the files if
> they exist, or fetch them and then verify if they do not. Once that is
> done, the mini-script removes the fetchlog which acts as a sort of flag
> to signal portmaster that it's done.
>
> If the fetch part of the process is completing, but the actual 'make
> checksum' target is not, that's an OS or ports infrastructure bug. If
> the fetch is not completing it could be an OS bug, or it could be a
> stalled/slow remote site, a bad Internet connection, or any of a
> half-dozen other things.
>
> Either way, I seriously doubt the code in portmaster is at fault. That
> code hasn't changed in many years.
>
> The only other thing I can think of to try is to start a build for one
> of the ports you're having trouble with (after removing the distfiles of
> course) and just let it run. While it's running, check these things:
>
> 1. Does the distfile actually get downloaded?
> 2. Does the fetch complete? That is, does the full file get downloaded,
> which matches the size and checksum in the distinfo file?
> 3. If the fetching of the file completes, does 'ps axww' show that a
> fetch process for that file is still underway?
> 4. If the fetching of the file completes, can you run 'make checksum' in
> the port directory and get a positive result?
> 5. What happens if you just let the portmaster process run for a few hours?
>
> Doug
--
Mit freundlichen Grüßen
Ing. Michael Ranner
GSM: +43 676 4155044
Mail: michael@ranner.eu
WWW: http://www.azedo.at/