From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11637 invoked by alias); 18 Nov 2019 15:31:59 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 11616 invoked by uid 89); 18 Nov 2019 15:31:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=disclose, UD:x86_64, db, DB X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Nov 2019 15:31:57 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id F3CB630003CD; Mon, 18 Nov 2019 16:31:54 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id A568D413CEAA; Mon, 18 Nov 2019 16:31:54 +0100 (CET) Message-ID: Subject: Re: patch 2/2 debuginfod server etc. From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org, amerey@redhat.com Date: Mon, 18 Nov 2019 15:31:00 -0000 In-Reply-To: <20191115195439.GC15272@redhat.com> References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <20191028190726.GE14349@redhat.com> <5356c862142d3221d91dc3f8767d6659639c61d9.camel@klomp.org> <20191115195439.GC15272@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00166.txt.bz2 Hi, On Fri, 2019-11-15 at 14:54 -0500, Frank Ch. Eigler wrote: > > > +set -x > >=20 > > Is this really necessary? > > It makes the log files very verbose. > > Or is that the intention? >=20 > I've found it tricky to debug failing tests without this. OK, but note that you can place echo "starting phase x..." in the test and those will show up in the logs. > > > +# find an unused port number > > > +while true; do > > > + PORT1=3D`expr '(' $RANDOM % 1000 ')' + 9000` > > > + ss -atn | fgrep ":$PORT1" || break > > > +done=20=20=20=20 > >=20 > > Which package does ss come from? >=20 > iproute-5.2.0-1.fc30.x86_64 >=20 > > Make sure it is listed as a BuildRequires. >=20 > OK, because of %check in the RPM? Yes, thanks. > > > +env LD_LIBRARY_PATH=3D$ldpath DEBUGINFOD_URLS=3D > > > ${abs_builddir}/../debuginfod/debuginfod -vvvv -d $DB \ > > > +-p $PORT1 -t0 -g0 R F & > > > +PID1=3D$! > > > +sleep 3 > >=20 > > Is there no better way to test the server has started? >=20 > This one may not be needed. >=20 > > > +mv prog F > > > +mv prog.debug F > > > +kill -USR1 $PID1 > > > +sleep 3 # give enough time for scanning pass=20 > >=20 > > Hmm that hardcoded sleep 3 again :{ >=20 > Well, here's the problem. We want to assert that the scan was > successful. We can't just reject a 404 response because the scan may > not have finished yet. So we'd have to race/loop/poll. But then we'd > need a timeout (how long?). It turns out to be the same thing, just > more complicated. >=20 >=20 > > > +mv testfile-debuginfod-0.rpm R > > > +mv testfile-debuginfod-1.rpm R > > > +mv testfile-debuginfod-2.rpm R > > > +kill -USR1 $PID1 > > > +sleep 10 > >=20 > > Why 10? >=20 > To give extra time for scanning RPMs. >=20 > > > +kill -USR1 $PID1 # two hits of SIGUSR1 may be needed to resolve .de= bug->dwz->srefs > > > +sleep 10 > >=20 > > And another :{ >=20 > Yes, again, same reasons as above. You can either have a timeout-poll > loop, or a time sleep and a single judgement poll. Now that we have the metrics maybe we can poll those to see if the new files have been indexed? The reason I am complaining about this, is that make check -j8 on my system takes (without valgrind): real 3m6.749s user 0m42.627s sys 0m31.588s Of which 2m seem to just be sleeps in run-debuginfod-find.sh. > > > +# Trigger a cache clean and run the tests again. The clients should = be unable to > > > +# find the target. > > > +echo 0 > $DEBUGINFOD_CACHE_PATH/cache_clean_interval_s > > > +echo 0 > $DEBUGINFOD_CACHE_PATH/max_unused_age_s > > > + > > > +testrun ${abs_builddir}/debuginfod_build_id_find -e F/prog 1 > > > + > > > +testrun ${abs_top_builddir}/debuginfod/debuginfod-find debuginfo $BU= ILDID2 && false || true > >=20 > > OK. But that means zero means never cache/always clean? > > I would have expected 0 to mean "forever". >=20 > I see the man page doesn't specifically disclose the interpretation of > zero. A "no retention of prior results" purpose is useful, and is > consistent with 0 as per the text. A "retain forever" setting would > have to be a different value. Could you add the current interpretation of zero to the manual page? We could have some other setting (-1?) for "forever", but that doesn't seem urgent. Cheers, Mark