--- Begin Message ---
|
Subject: |
failed builds due to exceeding max-silent-time not marked as failed in db |
|
Date: |
Wed, 2 Dec 2015 23:03:07 +0100 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
-----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-----
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: 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 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Florian Paul Schmidt <address@hidden> 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’.
--- End Message ---