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

From: Florian Paul Schmidt <[email-masked]>
Date: Mon, 14 Dec 2015 09:39:02 +0100

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.

> 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? 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.

In general it would probably be good to have a way of resetting the
cached failures in the db. 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?

> 
> 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).

Flo

- -- 
https://fps.io