GNU bug report logs - #22078
failed builds due to exceeding max-silent-time not marked as failed in db

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: tracker <at> debbugs.gnu.org
Subject: bug#22078: closed (failed builds due to exceeding max-silent-time
 not marked as failed in db)
Date: Mon, 14 Dec 2015 16:41:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 14 Dec 2015 17:40:21 +0100
with message-id <87mvtdx9u2.fsf <at> gnu.org>
and subject line Re: bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
has caused the debbugs.gnu.org bug report #22078,
regarding failed builds due to exceeding max-silent-time not marked as failed in db
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
22078: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22078
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Florian Paul Schmidt <mista.tapas <at> gmx.net>
To: bug-guix <at> gnu.org
Subject: failed builds due to exceeding max-silent-time not marked as failed
 in db
Date: Wed, 2 Dec 2015 23:03:07 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Hi,

on my system bulding the derivation for the package tbb (version
4.3.2) does not complete due to exceeding the max-silent-time default
value of 3600 seconds (one hour).

It seems that in this case the path is not marked as failed in the
sqlite3 db

/var/guix/db/db.sqlite

in the table FailedPaths. This is quite annoying since it seems that
several packages depend on it causing the derivation to be built
several times (each taking over an hour to fail).

The guix daemon is running with the --cache-failures option and I
would expect the second run of

for n in `guix package -A | cut -f1`; do guix build --no-substitutes
"$n" || true; done

to be mostly a NOOP, since all failures from the first run should be
cached. And even in the first run I wouldn't expect failed
dependencies to be tried to build again. Contrary to this on this box
even the second run of this takes about half a day or so to complete ;)

Flo

P.S.: FYI: The thing that takes over an hour to run is

./test_atomic.exe


- -- 
https://fps.io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWX2qaAAoJEA5f4Coltk8ZnasH/jOg+E0Y/CDxw5SGgcJN0Q6K
TYo41AVz0u9tLJEVYW4ZW9Z7A3UL5OTB+03LwC1zT7iDtFzU6a7BzaW2N3gP+GGi
Tx+Rq0z7ZIHEF1t71YFtPOAIpuyxwl1yMnRo0kd8BVsrNu843ITI4w+kzGV4tcP1
l9uDf7c+WQ8MFhoMDUqjW5ufIb3zy6yKk1GDXw14xZ8laeiE8hrXFE2LFV4WCxzP
VMPDgHBlPF6pAKLYpWSpL2RtL/WxO9tYIYpQ16EW7GjOouCy2ObT+1CJ75kSIOie
DZ/RLUSxa39amDFwii5liR+ETgvz3FCoBAcyI5AP/76uMToub1z3S1PNt58EnsE=
=Hivd
-----END PGP SIGNATURE-----

[Message part 3 (message/rfc822, inline)]

From: ludo <at> gnu.org (Ludovic Courtès)
To: Florian Paul Schmidt <mista.tapas <at> gmx.net>
Cc: 22078-done <at> debbugs.gnu.org
Subject: Re: bug#22078: failed builds due to exceeding max-silent-time not
 marked as failed in db
Date: Mon, 14 Dec 2015 17:40:21 +0100

Florian Paul Schmidt <mista.tapas <at> gmx.net> skribis:

> On 14.12.2015 00:11, Ludovic Courtès wrote:
>
>> OK.  I’m unsure whether it makes sense to cache failures due to
>> timeout because, by definition, they’re non-deterministic.
>
> Except for cases where they are deterministic (Consider a buggy
> package that has a testcase that reduces to while (true) { } that is
> not optimized away). They very seldom are though. Ayways: I'm not
> proposing to make any of this the default.

Yes.

>> Another problem is that clients can choose what the timeout is
>> (both max-silent-time and absolute max-time), so it’d be easy for a
>> client to force a timeout failure; on a multi-user system, that
>> would amount to a DoS attack.
>
> You mean a user just builds all packages with a timeout that's
> impossible to fulfill? And consequently all their failures will be
> cached and if then another user tries to build them they just get the
> cached failure?

Right.

> That points out another (though more contrived) flaw indeed:
>
> Even without caching failures a package might be nondeterministic for
> some reason (bugs always happen). A user who knows how to trigger the
> failure (assuming it's depending on something under the user's
> control) then could DOS that particular build.

That’s very unlikely because builds are performed under a separate UID,
in a container.

> In general it would probably be good to have a way of resetting the
> cached failures in the db.

One can do:

  guix gc --clear-failures $(guix gc --list-failures)

> Maybe --check does almost this: If a failed derivation gets built
> again with --check will the subsequent success overwrite the failed
> one and remove the entry from the FailedPaths table? Or will --check
> just happily report that the build is nondeterministic?

Good question.  I guess --check would just do nothing, but I haven’t
checked.

>> I’m not sure how to address these issues, so I’m rather in favor of
>> the status quo.
>
> I found that the changes I made don't seem to work correctly anyways.
> So LNGTMUAC (let's not get that merged under any circumstances).

Heh, OK.  :-)

In general, I expect there should be very few packages that get stuck
forever (like Chicken currently), and it’s obviously a bug to fix.  So I
guess we can simply live. with the possibility that occasionally your
machine will be trying to build Chicken and fail again.  ;-)  You can
always choose a smaller timeout anyway.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.