Issues with downloading vboxwrapper* and vm_isocontext* files #46
Comments
km-git-acc
changed the title
|
Currently I have partially solved the problem this way, Since everything works on a fresh start, if things freeze the overall flow is to 1) create a mysql backup, 2) issue a down -v command, 3) issue a up -d --build command, 4) issue a down command, 5) restore the modified backup, 6) issue a up -d command Also, it's possible the original problem will be faced quite rarely. On revisiting everything that was done, it seems I had additionally first started the boinc server with a numeric ip, then while some tasks were running in the clients, I purchased a domain name and linked it to a new ip. Then i restarted the boinc server using the domain name. This may have affected some of the results and workunit tables, though not really sure about that. |
|
@marius311 |
|
Experiencing the same issue. Download stuck on vboxwrapper_26198_x86_64-pc-linux-gnu and vm_isocontext_v1.0.0.iso. |
I have been setting up a boinc server using the boinc-server-docker framework. After editing a few files and using a custom build using the --build option, I was able to successfully launch the server and submit a few jobs, which completed and reported back as well.
To test things further on the client side, I removed the project and added it back again using existing credentials. On submitting some jobs and asking the client to request an update, a new job starts downloading along with all the required files (which got deleted from my local machine while removing the project).
However, the Transfers tab shows that only the layer and similar files are now successfully downloaded. Two files vboxwrapper* and vm_isocontext* get stuck at 0% and the boinc manager keeps retrying periodically (this has happened to both me on my Windows machine as well as a collaborator on his Mac)
On the server side, I tried for eg. from within the project folder
This apparently resolved the issue on the Windows machine, although the problem persisted at the Mac end. Hence I later again tried out 1) restarting the physical server, 2) restarting the project as above, 3) detaching/attaching the project from the client side, and the problem has now recurred on the Windows machine as well.
I looked at the event logs generated, and posting the logs post the update request
I tried to check the apache logs on the server, but they point to /dev/stdout and /dev/stderr hence haven't been able to check them.
On trying to check logs from the host environment, for eg.
docker logs dbnupperbound_apache_1, I get several reap messages at the endGiven that most task files are getting downloaded, it seems I am missing something obvious, but haven't been able to figure it out. Great if you could point in the right direction.
EDIT:
Also, an approach which had worked in the past, but haven't been able to replicate this time. I tried a hard reset by first backing up the mysql database, then using docker-compose down -v, then the normal up -d --build command, and then restoring the mysql database. Post that a project detach/attach at the client side. While all the user and workunit information is retained, and again the Transfers tab shows the layer files getting downloaded, the two v* files stay at 0%.
EDIT2:
On a replica vm, I followed all the steps except importing the mysql backup, and it worked! Ofcourse this cannot be a feasible option once a project has run for some aount of time, hence I have been searching for a series of steps to use in a crisis scenario, before scaling things up.
In the main server, there have been some abandoned tasks over the past 2 days, and some tasks which are still in progress but pending the v* file transfer. Is it possible these are creating some kind of bottleneck?
The text was updated successfully, but these errors were encountered: