Florian Paul Schmidt <mista.ta...@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’.
