From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: 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 Message-ID: <87mvtdx9u2.fsf@gnu.org> References: <565F6A9B.9050406@gmx.net> <56621663.4080007@gmx.net> <87a8peuep0.fsf@gnu.org> <566E8026.6070903@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8WBO-0003lT-O5 for bug-guix@gnu.org; Mon, 14 Dec 2015 11:41:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8WBK-0006xk-NC for bug-guix@gnu.org; Mon, 14 Dec 2015 11:41:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:44174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8WBK-0006xg-Ks for bug-guix@gnu.org; Mon, 14 Dec 2015 11:41:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a8WBK-0002s2-Gs for bug-guix@gnu.org; Mon, 14 Dec 2015 11:41:02 -0500 Sender: "Debbugs-submit" Resent-To: bug-guix@gnu.org Resent-Message-ID: In-Reply-To: <566E8026.6070903@gmx.net> (Florian Paul Schmidt's message of "Mon, 14 Dec 2015 09:39:02 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Florian Paul Schmidt Cc: 22078-done@debbugs.gnu.org Florian Paul Schmidt skribis: > On 14.12.2015 00:11, Ludovic Court=C3=A8s wrote: > >> OK. I=E2=80=99m unsure whether it makes sense to cache failures due to >> timeout because, by definition, they=E2=80=99re 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=E2=80=99d be easy fo= r 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=E2=80=99s 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=E2=80=99t checked. >> I=E2=80=99m not sure how to address these issues, so I=E2=80=99m 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=E2=80=99s 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=E2=80=99.