From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Paul Schmidt Subject: bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db Date: Mon, 14 Dec 2015 09:39:02 +0100 Message-ID: <566E8026.6070903@gmx.net> References: <565F6A9B.9050406@gmx.net> <56621663.4080007@gmx.net> <87a8peuep0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8Ofv-0005Km-1u for bug-guix@gnu.org; Mon, 14 Dec 2015 03:40:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8Ofq-0001bi-VX for bug-guix@gnu.org; Mon, 14 Dec 2015 03:40:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:43277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8Ofq-0001be-Ro for bug-guix@gnu.org; Mon, 14 Dec 2015 03:40:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a8Ofq-0006fJ-H2 for bug-guix@gnu.org; Mon, 14 Dec 2015 03:40:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87a8peuep0.fsf@gnu.org> 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 22078@debbugs.gnu.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWboAmAAoJEA5f4Coltk8Zhe4H/2B8jFpvjyTCn87eRoPCVjYV 3bHgjl/WXByrei93l65q+TY+IxFxA66p1Q9GV/cBoj7k/gkFxylUamaqw0wbQEbm yohD0G7YnKpywXCLp1pwJeFeBUGmAe/F0Fw4G45OGcAeIQ7AbDZRHmYq4KRe9x1q i0n96plAirsy5zvBY88bdZU8Fbc4c8pm1Mw2e8B9i3EEWjwcXh8UWeuerTKHhMK4 KNtxgX+Wnx05ZmzOnM3yJKOM8qgujW4peYhVJl3SRAMv/5kLFVCOOUC3XbsijdMM 8ny68tXgE5pNtfHsGko/rqwBT/LQ0C94zO+ggkitd51sgLFKXMRdt+j9pmDLfS0= =ZFzw -----END PGP SIGNATURE-----