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

[Ludovic Courtès]

Florian Paul Schmidt <address@hidden> 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’.