* bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
@ 2015-12-02 22:03 Florian Paul Schmidt
2015-12-04 22:40 ` Florian Paul Schmidt
0 siblings, 1 reply; 6+ messages in thread
From: Florian Paul Schmidt @ 2015-12-02 22:03 UTC (permalink / raw)
To: 22078
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
on my system bulding the derivation for the package tbb (version
4.3.2) does not complete due to exceeding the max-silent-time default
value of 3600 seconds (one hour).
It seems that in this case the path is not marked as failed in the
sqlite3 db
/var/guix/db/db.sqlite
in the table FailedPaths. This is quite annoying since it seems that
several packages depend on it causing the derivation to be built
several times (each taking over an hour to fail).
The guix daemon is running with the --cache-failures option and I
would expect the second run of
for n in `guix package -A | cut -f1`; do guix build --no-substitutes
"$n" || true; done
to be mostly a NOOP, since all failures from the first run should be
cached. And even in the first run I wouldn't expect failed
dependencies to be tried to build again. Contrary to this on this box
even the second run of this takes about half a day or so to complete ;)
Flo
P.S.: FYI: The thing that takes over an hour to run is
./test_atomic.exe
- --
https://fps.io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWX2qaAAoJEA5f4Coltk8ZnasH/jOg+E0Y/CDxw5SGgcJN0Q6K
TYo41AVz0u9tLJEVYW4ZW9Z7A3UL5OTB+03LwC1zT7iDtFzU6a7BzaW2N3gP+GGi
Tx+Rq0z7ZIHEF1t71YFtPOAIpuyxwl1yMnRo0kd8BVsrNu843ITI4w+kzGV4tcP1
l9uDf7c+WQ8MFhoMDUqjW5ufIb3zy6yKk1GDXw14xZ8laeiE8hrXFE2LFV4WCxzP
VMPDgHBlPF6pAKLYpWSpL2RtL/WxO9tYIYpQ16EW7GjOouCy2ObT+1CJ75kSIOie
DZ/RLUSxa39amDFwii5liR+ETgvz3FCoBAcyI5AP/76uMToub1z3S1PNt58EnsE=
=Hivd
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
2015-12-02 22:03 bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db Florian Paul Schmidt
@ 2015-12-04 22:40 ` Florian Paul Schmidt
2015-12-09 19:57 ` Leo Famulari
2015-12-13 23:11 ` Ludovic Courtès
0 siblings, 2 replies; 6+ messages in thread
From: Florian Paul Schmidt @ 2015-12-04 22:40 UTC (permalink / raw)
To: 22078
[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]
Attached is a first stab at fixing this. There are additional options to
guix-daemons now:
--cache-failures cache build failures
--cache-hook-failures cache build failures due to hook failures
(depends
on cache-failures)
--cache-timeout-failures cache build failures due to timeouts
(depends
on cache-failures)
Patch compiles, but is yet untested since the system I need it has gone
away for the time being..
Flo
On 12/02/2015 11:03 PM, Florian Paul Schmidt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> Hi,
>
> on my system bulding the derivation for the package tbb (version
> 4.3.2) does not complete due to exceeding the max-silent-time default
> value of 3600 seconds (one hour).
>
> It seems that in this case the path is not marked as failed in the
> sqlite3 db
>
> /var/guix/db/db.sqlite
>
> in the table FailedPaths. This is quite annoying since it seems that
> several packages depend on it causing the derivation to be built
> several times (each taking over an hour to fail).
>
> The guix daemon is running with the --cache-failures option and I
> would expect the second run of
>
> for n in `guix package -A | cut -f1`; do guix build --no-substitutes
> "$n" || true; done
>
> to be mostly a NOOP, since all failures from the first run should be
> cached. And even in the first run I wouldn't expect failed
> dependencies to be tried to build again. Contrary to this on this box
> even the second run of this takes about half a day or so to complete ;)
>
> Flo
>
> P.S.: FYI: The thing that takes over an hour to run is
>
> ./test_atomic.exe
>
>
> - --
> https://fps.io
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWX2qaAAoJEA5f4Coltk8ZnasH/jOg+E0Y/CDxw5SGgcJN0Q6K
> TYo41AVz0u9tLJEVYW4ZW9Z7A3UL5OTB+03LwC1zT7iDtFzU6a7BzaW2N3gP+GGi
> Tx+Rq0z7ZIHEF1t71YFtPOAIpuyxwl1yMnRo0kd8BVsrNu843ITI4w+kzGV4tcP1
> l9uDf7c+WQ8MFhoMDUqjW5ufIb3zy6yKk1GDXw14xZ8laeiE8hrXFE2LFV4WCxzP
> VMPDgHBlPF6pAKLYpWSpL2RtL/WxO9tYIYpQ16EW7GjOouCy2ObT+1CJ75kSIOie
> DZ/RLUSxa39amDFwii5liR+ETgvz3FCoBAcyI5AP/76uMToub1z3S1PNt58EnsE=
> =Hivd
> -----END PGP SIGNATURE-----
>
>
>
[-- Attachment #2: 0001-guix-daemon-cache-more-failures-if-requested.patch --]
[-- Type: text/plain, Size: 4527 bytes --]
From 3e376f7d22a62c19491d830c34182f2f4828f0a3 Mon Sep 17 00:00:00 2001
From: Florian Paul Schmidt <mista.tapas@gmx.net>
Date: Fri, 4 Dec 2015 23:37:13 +0100
Subject: [PATCH] guix-daemon: cache more failures if requested
---
nix/libstore/build.cc | 8 ++++++++
nix/libstore/globals.cc | 4 ++++
nix/libstore/globals.hh | 6 ++++++
nix/nix-daemon/guix-daemon.cc | 12 ++++++++++++
4 files changed, 30 insertions(+)
diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
index efe1ab2..48936f9 100644
--- a/nix/libstore/build.cc
+++ b/nix/libstore/build.cc
@@ -1483,12 +1483,20 @@ void DerivationGoal::buildDone()
if (settings.printBuildTrace)
printMsg(lvlError, format("@ build-failed %1% - timeout") % drvPath);
worker.timedOut = true;
+
+ if (settings.cacheFailure && settings.cacheTimeoutFailure)
+ foreach (DerivationOutputs::iterator, i, drv.outputs)
+ worker.store.registerFailedPath(i->second.path);
}
else if (hook && (!WIFEXITED(status) || WEXITSTATUS(status) != 100)) {
if (settings.printBuildTrace)
printMsg(lvlError, format("@ hook-failed %1% - %2% %3%")
% drvPath % status % e.msg());
+
+ if (settings.cacheFailure && settings.cacheHookFailure)
+ foreach (DerivationOutputs::iterator, i, drv.outputs)
+ worker.store.registerFailedPath(i->second.path);
}
else {
diff --git a/nix/libstore/globals.cc b/nix/libstore/globals.cc
index 07f23d4..7829c1c 100644
--- a/nix/libstore/globals.cc
+++ b/nix/libstore/globals.cc
@@ -48,6 +48,8 @@ Settings::Settings()
compressLog = true;
maxLogSize = 0;
cacheFailure = false;
+ cacheTimeoutFailure = false;
+ cacheHookFailure = false;
pollInterval = 5;
checkRootReachability = false;
gcKeepOutputs = false;
@@ -158,6 +160,8 @@ void Settings::update()
_get(compressLog, "build-compress-log");
_get(maxLogSize, "build-max-log-size");
_get(cacheFailure, "build-cache-failure");
+ _get(cacheTimeoutFailure, "build-cache-timeout-failure");
+ _get(cacheHookFailure, "build-cache-hook-failure");
_get(pollInterval, "build-poll-interval");
_get(checkRootReachability, "gc-check-reachability");
_get(gcKeepOutputs, "gc-keep-outputs");
diff --git a/nix/libstore/globals.hh b/nix/libstore/globals.hh
index c17e10d..bf8666a 100644
--- a/nix/libstore/globals.hh
+++ b/nix/libstore/globals.hh
@@ -170,6 +170,12 @@ struct Settings {
/* Whether to cache build failures. */
bool cacheFailure;
+ /* Whether to cache timeout failures */
+ bool cacheTimeoutFailure;
+
+ /* Whether to cache hook failures */
+ bool cacheHookFailure;
+
/* How often (in seconds) to poll for locks. */
unsigned int pollInterval;
diff --git a/nix/nix-daemon/guix-daemon.cc b/nix/nix-daemon/guix-daemon.cc
index 1934487..f613de9 100644
--- a/nix/nix-daemon/guix-daemon.cc
+++ b/nix/nix-daemon/guix-daemon.cc
@@ -80,6 +80,8 @@ builds derivations on behalf of its clients.");
#define GUIX_OPT_NO_BUILD_HOOK 14
#define GUIX_OPT_GC_KEEP_OUTPUTS 15
#define GUIX_OPT_GC_KEEP_DERIVATIONS 16
+#define GUIX_OPT_CACHE_TIMEOUT_FAILURES 17
+#define GUIX_OPT_CACHE_HOOK_FAILURES 18
static const struct argp_option options[] =
{
@@ -104,6 +106,10 @@ static const struct argp_option options[] =
n_("do not use the 'build hook'") },
{ "cache-failures", GUIX_OPT_CACHE_FAILURES, 0, 0,
n_("cache build failures") },
+ { "cache-timeout-failures", GUIX_OPT_CACHE_TIMEOUT_FAILURES, 0, 0,
+ n_("cache build failures due to timeouts (depends on cache-failures)") },
+ { "cache-hook-failures", GUIX_OPT_CACHE_HOOK_FAILURES, 0, 0,
+ n_("cache build failures due to hook failures (depends on cache-failures)") },
{ "lose-logs", GUIX_OPT_LOSE_LOGS, 0, 0,
n_("do not keep build logs") },
{ "disable-log-compression", GUIX_OPT_DISABLE_LOG_COMPRESSION, 0, 0,
@@ -189,6 +195,12 @@ parse_opt (int key, char *arg, struct argp_state *state)
case GUIX_OPT_CACHE_FAILURES:
settings.cacheFailure = true;
break;
+ case GUIX_OPT_CACHE_TIMEOUT_FAILURES:
+ settings.cacheTimeoutFailure = true;
+ break;
+ case GUIX_OPT_CACHE_HOOK_FAILURES:
+ settings.cacheHookFailure = true;
+ break;
case GUIX_OPT_IMPERSONATE_LINUX_26:
settings.impersonateLinux26 = true;
break;
--
2.5.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
2015-12-04 22:40 ` Florian Paul Schmidt
@ 2015-12-09 19:57 ` Leo Famulari
2015-12-13 23:11 ` Ludovic Courtès
1 sibling, 0 replies; 6+ messages in thread
From: Leo Famulari @ 2015-12-09 19:57 UTC (permalink / raw)
To: Florian Paul Schmidt; +Cc: 22078
On Fri, Dec 04, 2015 at 11:40:35PM +0100, Florian Paul Schmidt wrote:
> Attached is a first stab at fixing this. There are additional options to
> guix-daemons now:
>
> --cache-failures cache build failures
> --cache-hook-failures cache build failures due to hook failures
> (depends
> on cache-failures)
> --cache-timeout-failures cache build failures due to timeouts
> (depends
> on cache-failures)
I see the value of this.
I wonder how it would change the semantics of the store? I think the
current failure caching system is only based on the hash of the
dependency graph. Is that correct? That reinforces the determinism of
the system.
It seems impossible to make build hook and timeout failures
deterministic. Both depend on things that can't be observed by the
daemon or the builder. So if these failures are cached, the caching
should be enabled separately from the memoized failures.
I think that if we do decide to cache timeout failures, the value of
"--timeout" and "--max-silent-time" should be included. I have a slow
machine that can't build certain packages with the default
"--max-silent-time" even when nothing is "competing" for the system's
resources. But of course there are other factors that affect this like
other processes on the system so it's not deterministic.
> Patch compiles, but is yet untested since the system I need it has gone away
> for the time being..
Have you tested the patch yet?
>
> Flo
>
> On 12/02/2015 11:03 PM, Florian Paul Schmidt wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA256
> >
> >
> >Hi,
> >
> >on my system bulding the derivation for the package tbb (version
> >4.3.2) does not complete due to exceeding the max-silent-time default
> >value of 3600 seconds (one hour).
> >
> >It seems that in this case the path is not marked as failed in the
> >sqlite3 db
> >
> >/var/guix/db/db.sqlite
> >
> >in the table FailedPaths. This is quite annoying since it seems that
> >several packages depend on it causing the derivation to be built
> >several times (each taking over an hour to fail).
> >
> >The guix daemon is running with the --cache-failures option and I
> >would expect the second run of
> >
> >for n in `guix package -A | cut -f1`; do guix build --no-substitutes
> >"$n" || true; done
> >
> >to be mostly a NOOP, since all failures from the first run should be
> >cached. And even in the first run I wouldn't expect failed
> >dependencies to be tried to build again. Contrary to this on this box
> >even the second run of this takes about half a day or so to complete ;)
> >
> >Flo
> >
> >P.S.: FYI: The thing that takes over an hour to run is
> >
> >./test_atomic.exe
> >
> >
> >- -- https://fps.io
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v2
> >
> >iQEcBAEBCAAGBQJWX2qaAAoJEA5f4Coltk8ZnasH/jOg+E0Y/CDxw5SGgcJN0Q6K
> >TYo41AVz0u9tLJEVYW4ZW9Z7A3UL5OTB+03LwC1zT7iDtFzU6a7BzaW2N3gP+GGi
> >Tx+Rq0z7ZIHEF1t71YFtPOAIpuyxwl1yMnRo0kd8BVsrNu843ITI4w+kzGV4tcP1
> >l9uDf7c+WQ8MFhoMDUqjW5ufIb3zy6yKk1GDXw14xZ8laeiE8hrXFE2LFV4WCxzP
> >VMPDgHBlPF6pAKLYpWSpL2RtL/WxO9tYIYpQ16EW7GjOouCy2ObT+1CJ75kSIOie
> >DZ/RLUSxa39amDFwii5liR+ETgvz3FCoBAcyI5AP/76uMToub1z3S1PNt58EnsE=
> >=Hivd
> >-----END PGP SIGNATURE-----
> >
> >
> >
>
> From 3e376f7d22a62c19491d830c34182f2f4828f0a3 Mon Sep 17 00:00:00 2001
> From: Florian Paul Schmidt <mista.tapas@gmx.net>
> Date: Fri, 4 Dec 2015 23:37:13 +0100
> Subject: [PATCH] guix-daemon: cache more failures if requested
>
> ---
> nix/libstore/build.cc | 8 ++++++++
> nix/libstore/globals.cc | 4 ++++
> nix/libstore/globals.hh | 6 ++++++
> nix/nix-daemon/guix-daemon.cc | 12 ++++++++++++
> 4 files changed, 30 insertions(+)
>
> diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
> index efe1ab2..48936f9 100644
> --- a/nix/libstore/build.cc
> +++ b/nix/libstore/build.cc
> @@ -1483,12 +1483,20 @@ void DerivationGoal::buildDone()
> if (settings.printBuildTrace)
> printMsg(lvlError, format("@ build-failed %1% - timeout") % drvPath);
> worker.timedOut = true;
> +
> + if (settings.cacheFailure && settings.cacheTimeoutFailure)
> + foreach (DerivationOutputs::iterator, i, drv.outputs)
> + worker.store.registerFailedPath(i->second.path);
> }
>
> else if (hook && (!WIFEXITED(status) || WEXITSTATUS(status) != 100)) {
> if (settings.printBuildTrace)
> printMsg(lvlError, format("@ hook-failed %1% - %2% %3%")
> % drvPath % status % e.msg());
> +
> + if (settings.cacheFailure && settings.cacheHookFailure)
> + foreach (DerivationOutputs::iterator, i, drv.outputs)
> + worker.store.registerFailedPath(i->second.path);
> }
>
> else {
> diff --git a/nix/libstore/globals.cc b/nix/libstore/globals.cc
> index 07f23d4..7829c1c 100644
> --- a/nix/libstore/globals.cc
> +++ b/nix/libstore/globals.cc
> @@ -48,6 +48,8 @@ Settings::Settings()
> compressLog = true;
> maxLogSize = 0;
> cacheFailure = false;
> + cacheTimeoutFailure = false;
> + cacheHookFailure = false;
> pollInterval = 5;
> checkRootReachability = false;
> gcKeepOutputs = false;
> @@ -158,6 +160,8 @@ void Settings::update()
> _get(compressLog, "build-compress-log");
> _get(maxLogSize, "build-max-log-size");
> _get(cacheFailure, "build-cache-failure");
> + _get(cacheTimeoutFailure, "build-cache-timeout-failure");
> + _get(cacheHookFailure, "build-cache-hook-failure");
> _get(pollInterval, "build-poll-interval");
> _get(checkRootReachability, "gc-check-reachability");
> _get(gcKeepOutputs, "gc-keep-outputs");
> diff --git a/nix/libstore/globals.hh b/nix/libstore/globals.hh
> index c17e10d..bf8666a 100644
> --- a/nix/libstore/globals.hh
> +++ b/nix/libstore/globals.hh
> @@ -170,6 +170,12 @@ struct Settings {
> /* Whether to cache build failures. */
> bool cacheFailure;
>
> + /* Whether to cache timeout failures */
> + bool cacheTimeoutFailure;
> +
> + /* Whether to cache hook failures */
> + bool cacheHookFailure;
> +
> /* How often (in seconds) to poll for locks. */
> unsigned int pollInterval;
>
> diff --git a/nix/nix-daemon/guix-daemon.cc b/nix/nix-daemon/guix-daemon.cc
> index 1934487..f613de9 100644
> --- a/nix/nix-daemon/guix-daemon.cc
> +++ b/nix/nix-daemon/guix-daemon.cc
> @@ -80,6 +80,8 @@ builds derivations on behalf of its clients.");
> #define GUIX_OPT_NO_BUILD_HOOK 14
> #define GUIX_OPT_GC_KEEP_OUTPUTS 15
> #define GUIX_OPT_GC_KEEP_DERIVATIONS 16
> +#define GUIX_OPT_CACHE_TIMEOUT_FAILURES 17
> +#define GUIX_OPT_CACHE_HOOK_FAILURES 18
>
> static const struct argp_option options[] =
> {
> @@ -104,6 +106,10 @@ static const struct argp_option options[] =
> n_("do not use the 'build hook'") },
> { "cache-failures", GUIX_OPT_CACHE_FAILURES, 0, 0,
> n_("cache build failures") },
> + { "cache-timeout-failures", GUIX_OPT_CACHE_TIMEOUT_FAILURES, 0, 0,
> + n_("cache build failures due to timeouts (depends on cache-failures)") },
> + { "cache-hook-failures", GUIX_OPT_CACHE_HOOK_FAILURES, 0, 0,
> + n_("cache build failures due to hook failures (depends on cache-failures)") },
> { "lose-logs", GUIX_OPT_LOSE_LOGS, 0, 0,
> n_("do not keep build logs") },
> { "disable-log-compression", GUIX_OPT_DISABLE_LOG_COMPRESSION, 0, 0,
> @@ -189,6 +195,12 @@ parse_opt (int key, char *arg, struct argp_state *state)
> case GUIX_OPT_CACHE_FAILURES:
> settings.cacheFailure = true;
> break;
> + case GUIX_OPT_CACHE_TIMEOUT_FAILURES:
> + settings.cacheTimeoutFailure = true;
> + break;
> + case GUIX_OPT_CACHE_HOOK_FAILURES:
> + settings.cacheHookFailure = true;
> + break;
> case GUIX_OPT_IMPERSONATE_LINUX_26:
> settings.impersonateLinux26 = true;
> break;
> --
> 2.5.0
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
2015-12-04 22:40 ` Florian Paul Schmidt
2015-12-09 19:57 ` Leo Famulari
@ 2015-12-13 23:11 ` Ludovic Courtès
2015-12-14 8:39 ` Florian Paul Schmidt
1 sibling, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2015-12-13 23:11 UTC (permalink / raw)
To: Florian Paul Schmidt; +Cc: 22078
Florian Paul Schmidt <mista.tapas@gmx.net> skribis:
> Attached is a first stab at fixing this. There are additional options
> to guix-daemons now:
>
> --cache-failures cache build failures
> --cache-hook-failures cache build failures due to hook failures
> (depends
> on cache-failures)
> --cache-timeout-failures cache build failures due to timeouts
> (depends
> on cache-failures)
OK. I’m unsure whether it makes sense to cache failures due to timeout
because, by definition, they’re non-deterministic.
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.
I’m not sure how to address these issues, so I’m rather in favor of the
status quo.
WDYT?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
2015-12-13 23:11 ` Ludovic Courtès
@ 2015-12-14 8:39 ` Florian Paul Schmidt
2015-12-14 16:40 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Florian Paul Schmidt @ 2015-12-14 8:39 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 22078
-----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-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db
2015-12-14 8:39 ` Florian Paul Schmidt
@ 2015-12-14 16:40 ` Ludovic Courtès
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2015-12-14 16:40 UTC (permalink / raw)
To: Florian Paul Schmidt; +Cc: 22078-done
Florian Paul Schmidt <mista.tapas@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’.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-12-14 16:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-02 22:03 bug#22078: failed builds due to exceeding max-silent-time not marked as failed in db Florian Paul Schmidt
2015-12-04 22:40 ` Florian Paul Schmidt
2015-12-09 19:57 ` Leo Famulari
2015-12-13 23:11 ` Ludovic Courtès
2015-12-14 8:39 ` Florian Paul Schmidt
2015-12-14 16:40 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.