while not copy-assignable it was still copy-constructible, which can
lead to some very unfortunate interactions with closure captures. we
will also need to move current-activity handles in upcoming changes.
Change-Id: I63cede83b9790820c6bd8784fb5d47e5246b7c4a
otherwise we may end up trying to delete a temporary directory that is
still actively being written to if a derivation is killed due to other
derivations failing or the build is aborted due to a user interruption
fixes#678
Change-Id: I4678723f11bdd261b27af8784d040a787690b107
This is mostly to deal with fatal errors in NixOS tests, but it's useful
for all cases; assertion failures landing in syslog would be nice too,
but that's not as easy to do.
CC: https://git.lix.systems/lix-project/lix/issues/693
Change-Id: I6b5bd9800db3f5affe33f2946ea218e4a78f0c07
This also adds documentation for it in distributed-builds.md as that's
possibly the most common use-case for remote ssh stores
Support for `std::optional<uint16_t>` in Setting is also added since
setting a port is optional.
The line `#include "lix/libutil/strings.hh"` fixes that templates instanciations
in lix/libutil/config-impl.hh were using string utils without including
the header (why are they even there btw)
Change-Id: Id806c117c48cdf158d9d1cb1e639b0df31d9bf11
also mark the sync version as NeverAsync. a blocking wait on sqlite
locks in a coroutine may never finish if it's a different coroutine
on the same executor that is holding the lock, not another process.
this propagates to the sqlite core interface, but no further. we'll
assume that caches do not block on a database for very long, and we
can't reasonably propagate never-async-ness out of stores unless we
touch everything we'd touch for the async transition, again, twice.
store code already assumes that it can block for however long it'll
feel like that moment. we keep thread pools around for this reason.
Change-Id: I62f77e1ac333cbe2e4e646dbcb1571463f2cf3fc
For the user manual, we don't delete things that are missing when doing
aws s3 sync. This doesn't seem wise. If you delete a page in the manual,
it will stay public and visible.
This adds `--delete` to the `aws s3 sync` commands to fix this issue.
Closes#396
Change-Id: I6d7fb97bcdab96c0115d6c66fea0310125207df4
this does not change the API exposed by the library, so it'll be safe
for users to substitute stock capnp. we do want it for our own builds
though, at least until we can switch to capnp 2 or fully go for rust.
Change-Id: Ia8ac6af0165f6f61ee02345179dc0a93a0889a06
4138fc7622 mistakenly removed an early
exit from non-main worker threads. this led to exceptions not ending
`process()` calls in a timely manner and instead draining the entire
work queue first, which for e.g. Interrupted errors would cause many
duplicated reports per worker thread instead of only one per thread.
it also did not properly rethrow a work item exception in all cases,
e.g. when all work had completed by the time `process()` was called.
due to a mistake in the thread starting check it was possible that a
system would require n² work items to start n worker threads if some
work items process quickly enough while other items block for a bit.
Change-Id: I7d59483580cda1c19980f9296074216a0fbf2c4e
* changes:
fix: pre-build-hook did not run when useChroot == false
libstore/build: say what was failing when pre/post build hooks fail
daemon: complain much louder about unknown std::exception instances falling out
The lix daemon wants to avoid orphan processes outliving a lix build.
In order to do that it kills all processes under the build user's UID
after and before a build.
When using sandboxes under Linux, this is unecessary, as builds are run
inside a PID namespace, which guarantees that processes cannot outlive
the "init" process.
Partially fixes https://git.lix.systems/lix-project/lix/issues/667
Change-Id: Idb2cdaad30169b75d730e8a18b360330516faf8b
Upgrading a read transaction to a write transaction will immediately
fail if another connection/process started a write transaction in the
meantime. For transactions that we expect to perform a write after a
read, starting with `BEGIN IMMEDIATE` gives us a write transaction
immediately instead of beginning with a read transaction and upgrading
it.
Change-Id: I82b8a3843382940a4fa4ffe45f30b365b690ff86
It turns out there is actually some history here.
Eight years ago, in 7f5b750b40, the
pre-build-hook condition got changed to check that useChroot is true
(which we will put down as "eelco making a mistake" because it makes no
sense) and that this->drv was a Derivation (as opposed to a
BasicDerivation as would be the case if the derivation was not present
on disk). The intent of this change was that pre-build-hook would not
run when the derivation doesn't exist, so that some hydras would not
explode.
However, this broke later when both cases became Derivation such that
AFAICT it will always run it if useChroot is true, which is absolutely
not the intended behaviour, but it is a reasonable interpretation as
well, just inconvenient for certain pre-build-hook usages.
So, I think the safest and most compatible behaviour is to run the
pre-build-hook but not guarantee that the derivation actually exists on
disk, since it already didn't run in many cases. Maybe the more correct
way is to actually write out the derivation if we are running a
pre-build-hook, but post-build-hook has exactly the same situation and
it's expected, so idk.
Fixes: https://git.lix.systems/lix-project/lix/issues/674
Change-Id: I75b828ae2a07ab373f44083507eb243459bd081d
Specifically, for errors where the provided and expected hashes differ.
Also, I've updated `fetchTarball`'s docs to explain the allowed values
for the `sha256` attribute.
Change-Id: Ic9aa777dc0a3c1ccdb4c98048745067f529bd986
Using time_t meant a warning could be printed arbitrarily soon depending
on when the second rolled over relative to when the SQLite transaction
was attempted.
Change-Id: I93401aea65f90e37cd450a293c4dd4d64fba7628
the two instances that used synchronous locking from promises weren't in
danger of deadlocks: both only serialized access to the sqlite database.
Change-Id: I2041a7a31f39cffde2080d0bb2402e2ead8d953f
eldritch horrors