Subject: bug#22078: closed (Re: bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 14 Dec 2015 16:41:02 +0000

Your bug report

#22078: failed builds due to exceeding max-silent-time not marked as failed in db

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
22078: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22078
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
From: [email-masked] (Ludovic Courtès)
To: Florian Paul Schmidt <[email-masked]>
Cc: [email-masked]
Date: Mon, 14 Dec 2015 17:40:21 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Florian Paul Schmidt <[email-masked]> 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’.

Subject: failed builds due to exceeding max-silent-time not marked as failed in db
From: Florian Paul Schmidt <[email-masked]>
To: [email-masked]
Date: Wed, 2 Dec 2015 23:03:07 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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