| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I'm seeing "Resource temporarily unavailable, try again" errors from GnuTLS,
mostly around the file uploads I think.
I'm not sure what's going on here, but it seems to happen when using multiple
threads in parallel. Anyway, this commit uses some mutexes to avoid uploading
files in parallel, and also improves error handling generally. I'm pretty sure
this isn't sufficient to fix the issue, but I could be looking in completely
the wrong place for the problem.
|
| | |
|
| |
|
|
| |
As the same time, I think I've seen issues with deleting links.
|
| |
|
|
| |
Given a failure.
|
| | |
|
| |
|
|
|
|
| |
primative-fork in Guile seems more trouble than its worth, the parent process
seemed to lock up frequently. I think using threads could be causing problems
with TLS, but at least it doesn't lock up completely.
|
| |
|
|
|
| |
As I think there's "Resource temporarily unavailable, try again." errors
coming from here...
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Otherwise old values persist if an agent has no allocated builds.
|
| |
|
|
| |
As I'm guessing this could block the thread for fibers.
|
| |
|
|
|
|
| |
Don't always substitute the derivation, just fetch it if it doesn't exist in
the database. Also just use the name of the derivation, only read it from the
disk when it needs storing in the database.
|
| | |
|
| | |
|
| |
|
|
| |
Or at least there shouldn't be.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Sometimes primitive-fork seems to hang, maybe related to a futex system
call. I think disabling the garbage collector helps avoid this.
|
| | |
|
| | |
|
| |
|
|
| |
In case of failures.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There were a few issues with the previous approach, I was concerned about
trying to write to the SQLite database from two processes, it's already
segfaulting occasionally when accessing it from just one. Additionally, the
client actions were already doing things that should happen in the coordinator
process, like allocating builds.
I'm trying to not turn this in to a web app, but not doing very well. Although
having this information and these actions available over the network does make
it possible to build a web app frontend, which I've had in mind.
|
| | |
|
| | |
|
| |
|
|
|
| |
Associate this with the coordinator, rather than having the logic in the agent
communication code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm looking to listen for client instructions ("build this", ...) maybe on a
UNIX socket, which looks to be possible with fibers, but doing this at the
same time as using a network socket for agent messaging requires more access
than run-server from the fibers web server module currently allows.
To get around this, patch the fibers web server run-server procedure to do
less, and do that instead in the guix-build-coordinator. This is somewhat
similar to what I think Cuirass does to allow it to do more with fibers.
This required messing with the current-fiber parameter in a couple more places
around threads, I'm not really sure why that problem has occurred now. This
current-fiber parameter issue should be resolved in the next fibers release.
One good thing with these changes is some behaviours not related to agent
communication, like triggering build allocation on startup have been moved out
of the agent communication code.
|
| |
|
|
|
|
|
| |
To make it clear this is what it's for. This makes it easier to allow other
ways of communicating with agent processes in the future, as well as making it
easier to set out how to also listen for client commands, which I'm thinking
about now.
|
| |
|
|
| |
Only move the file in to the destination location when the upload completes.
|
| |
|
|
|
|
| |
When only starting from builds where the derivation isn't used in other
derivations, you risk missing parts of the derivation graph that aren't
covered with builds.
|
| |
|
|
|
|
| |
It was returning multiple records for a build, if that build could be reached
through multiple paths in the graph, resulting in different priorities. Only
the max priority matters, so have the query find that.
|
| |
|
|
| |
On newer version of Guix with guile-3.0.
|
| |
|
|
|
| |
Just eliminate processed builds at the end, otherwise parts of the graph could
be left unexplored.
|
| |
|
|
| |
Recent versions of Guix lack guile3.0-readline, so define it.
|
| |
|
|
| |
As it doesn't seem to be working, the backtrace printed is non-existent.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Use EXCEPT, rather than NOT IN to make the SQL query faster. Also, just return
and use the build id, rather than a alist.
|
| |
|
|
|
| |
If an allocation is triggered while one is in progress, store the need to
allocate again in an atomic box.
|
| |
|
|
|
|
|
| |
It worked under some database conditions, but was very slow under others. Move
more of the logic in to SQL in an attempt to make the allocator faster. This
sort of works, but there were some advantages to the approach before the
approach being replaced in this commit.
|
| | |
|
| |
|
|
| |
To use with the derivation ordered allocator.
|
| |
|
|
|
| |
Previously it was ignoring outputs without builds or build results. This fixes
that.
|