Change of hosts.txt is a stupid idea! There should be another way.

No, it's not stupid. It worked fine for me. I uploaded and got validated 14 4-hour tasks, that's 56 hours of computing.

On Linux is /etc/hosts.

Replace of "srv1.bakerlab.org" in client_state.xml is useless. Whenever i restart the boinc manager is it again there. I can't find from where boinc restore this.
i have it also replace in client_state_prev.xml.

Yep, that is what I was worried about.

Thanks your lazy guys have i now two WU's lost! 24 hours of work for nothing.

See above.

..., we're all on the same team here man :)

No! That is wrong, they need us, we don't.
They get money for the job. I spend money, for hardware and for power. I spend my spare time for maintenance of my systems to keep them always crunching.
Later, in an hopefully no so far future, if the first results come to the market, pay i again to get the medicine or whatever.

I share this point, but - you know - BOINC is plenty of medicine projects. If Rosetta@home is not always reliable or doesn't meet your demands, you can choose another project to place side by side or to replace it.

For example I don't run Rosetta@home tasks very much cause of inefficiency, but it is off-topic. Anyway 3.73 app sounds more cpu-intensive to me.

It is not our problem that srv1 is not responding. And it is not on us to implement a solution for that. Even more, if the solution is so damn stupid. 99% of the users will forget that they have made this change an will later have another problems only caused by this solution!

I think it is much better to change the server redirection at your side. Then can you spend all time you need to find out what is wrong. Especially since the weekend is at the doorstep.

---

99% of the users will forget that they have made this change an will later have another problems only caused by this solution!

Maybe not. These servers will be both online, so there could be no difference in the future. For forgetful users it could be fine to edit hosts file to upload only and to comment that line right after upload process.

I'm agree we should not do any special configuration. We should run BOINC only.

Not our problem, but we want our work to get validated too.

Temporary fix in place (modified hosts file). Thanks, whoever proposed it!

My suspicions confirmed;

• srv1.bakerlab.org at 128.95.160.142 is not working / not accepting uploads
  
• srv4.bakerlab.org at 128.95.160.145 is accepting uploads
  

All tasks that are trying to be uploaded to the first server are failing, while any tasks attempt to be sent to srv4.bakerlab.org successfully upload.

No go for me.

Here is the line I added:
128.95.160.145    srv1.bakerlab.org, in accordance with these instructions.

Here is the Event log:

6/24/2016 4:48:10 PM | rosetta@home | update requested by user
6/24/2016 4:48:15 PM | rosetta@home | Sending scheduler request: Requested by user.
6/24/2016 4:48:15 PM | rosetta@home | Not requesting tasks: too many uploads in progress
6/24/2016 4:48:17 PM | rosetta@home | Scheduler request completed

My suspicions confirmed;

• srv1.bakerlab.org at 128.95.160.142 is not working / not accepting uploads
  
• srv4.bakerlab.org at 128.95.160.145 is accepting uploads
  

All tasks that are trying to be uploaded to the first server are failing, while any tasks attempt to be sent to srv4.bakerlab.org successfully upload.

No go for me.

Here is the line I added:
128.95.160.145    srv1.bakerlab.org, in accordance with these instructions.

Here is the Event log:

6/24/2016 4:48:10 PM | rosetta@home | update requested by user
6/24/2016 4:48:15 PM | rosetta@home | Sending scheduler request: Requested by user.
6/24/2016 4:48:15 PM | rosetta@home | Not requesting tasks: too many uploads in progress
6/24/2016 4:48:17 PM | rosetta@home | Scheduler request completed

This fix is not to help with Requesting new tasks, but rather to help get your uploads going again. Judging from the snippet of your log file that you shared, you were attempting to fetch new work..

Go to your transfers tab and click one of your Uploading tasks that is stuck on 'Retry in ....' and click Retry Now - it should work.

Also, if you want to check that your hosts modification worked, you can attempt to visit this link http://srv1.bakerlab.org/ and it should bring you to the Rosetta@Home homepage :) Alternatively, you can ping srv1.bakerlab.org

Cheers

---

**38 cores crunching for R@H on behalf of cancercomputer.org - a non-profit supporting High Performance Computing in Cancer Research

This fix is not to help with Requesting new tasks, but rather to help get your uploads going again. Judging from the snippet of your log file that you shared, you were attempting to fetch new work..

Go to your transfers tab and click one of your Uploading tasks that is stuck on 'Retry in ....' and click Retry Now - it should work.

Also, if you want to check that your hosts modification worked, you can attempt to visit this link http://srv1.bakerlab.org/ and it should bring you to the Rosetta@Home homepage :) Alternatively, you can ping srv1.bakerlab.org

Cheers

I went to the Tasks tab and clicked Update.  I thought that was an all-inclusive request.  Retry Now worked, all "uploading" WUs are gone.  Just need to remember to undo mod to hosts file if problem is fixed.

Thank you Timo

I am running BOINC on Linux machines headless. After updating /etc/hosts with 128.95.160.145 srv1.bakerlab.org they still weren't able to upload recent work. I control BOINC through boinctui but couldn't find a way to force retrying of upload. The solution I found was to restart BOINC after the hosts file edit, then the uploads retried, and successfully uploaded. On a recent Debian system or derivative (Ubuntu and more), BOINC is restarted from the terminal by running sudo systemctl restart boinc.

Without making any changes to any hosts files and simply waiting (While still crunching at least), all my completed tasks finally uploaded and I got credit for them. Looks like they fixed it.

I am running BOINC on Linux machines headless. After updating /etc/hosts with 128.95.160.145 srv1.bakerlab.org they still weren't able to upload recent work. I control BOINC through boinctui but couldn't find a way to force retrying of upload. The solution I found was to restart BOINC after the hosts file edit, then the uploads retried, and successfully uploaded. On a recent Debian system or derivative (Ubuntu and more), BOINC is restarted from the terminal by running sudo systemctl restart boinc.

Yes, on Xubuntu you didn't need restarting BOINC to get hosts modifications effective and I'm not running BOINC as a service.

You could have tried

$boinccmd --get_file_transfers

Then

$boinccmd --file_transfer https://boinc.bakerlab.org/rosetta $filename retry

where $boinccmd is your boinccmd command including path and $filename is the result you want try to reupload.

Or simply

$boinccmd --set_network_mode never
$boinccmd --set_network_mode auto

and retry should be automatic.

See boinccmd.

Without making any changes to any hosts files and simply waiting (While still crunching at least), all my completed tasks finally uploaded and I got credit for them. Looks like they fixed it.

That solution was recommended for people having near-deadline tasks. Some robetta (rb_*) tasks were expiring on 24/06.

It seems that the Problem is fixed. Thank you guys very much!

---

This. Again.

28/06/2016 07:45:22 | rosetta@home | Computation for task gr062216_EEHEE_rd3_1211_fragments_fold_SAVE_ALL_OUT_384881_10_0 finished
28/06/2016 07:45:24 | rosetta@home | Started upload of gr062216_EEHEE_rd3_1211_fragments_fold_SAVE_ALL_OUT_384881_10_0_0
28/06/2016 07:46:07 | rosetta@home | Temporarily failed upload of gr062216_EEHEE_rd3_1211_fragments_fold_SAVE_ALL_OUT_384881_10_0_0: transient HTTP error
28/06/2016 07:46:07 | rosetta@home | Backing off 00:02:21 on upload of gr062216_EEHEE_rd3_1211_fragments_fold_SAVE_ALL_OUT_384881_10_0_0
28/06/2016 07:47:26 | rosetta@home | Started upload of gr062216_EEHEE_rd3_1211_fragments_fold_SAVE_ALL_OUT_384881_10_0_0
28/06/2016 07:48:13 | rosetta@home | Temporarily failed upload of gr062216_EEHEE_rd3_1211_fragments_fold_SAVE_ALL_OUT_384881_10_0_0: transient HTTP error
28/06/2016 07:48:13 | rosetta@home | Backing off 00:04:05 on upload of gr062216_EEHEE_rd3_1211_fragments_fold_SAVE_ALL_OUT_384881_10_0_0

---

And again.

04/08/2016 08:14:54 | rosetta@home | Started upload of FFD__300b59433e13d029e07395f92f38637f_abinitioDocking_16_08_09_53_15_globalDocking_7_SAVE_ALL_OUT_406840_18_0_0
04/08/2016 08:15:16 | rosetta@home | Temporarily failed upload of FFD__300b59433e13d029e07395f92f38637f_abinitioDocking_16_08_09_53_15_globalDocking_7_SAVE_ALL_OUT_406840_18_0_0: transient HTTP error
04/08/2016 08:15:16 | rosetta@home | Backing off 00:41:38 on upload of FFD__300b59433e13d029e07395f92f38637f_abinitioDocking_16_08_09_53_15_globalDocking_7_SAVE_ALL_OUT_406840_18_0_0

---

And again.

04/08/2016 08:14:54 | rosetta@home | Started upload of FFD__300b59433e13d029e07395f92f38637f_abinitioDocking_16_08_09_53_15_globalDocking_7_SAVE_ALL_OUT_406840_18_0_0
04/08/2016 08:15:16 | rosetta@home | Temporarily failed upload of FFD__300b59433e13d029e07395f92f38637f_abinitioDocking_16_08_09_53_15_globalDocking_7_SAVE_ALL_OUT_406840_18_0_0: transient HTTP error
04/08/2016 08:15:16 | rosetta@home | Backing off 00:41:38 on upload of FFD__300b59433e13d029e07395f92f38637f_abinitioDocking_16_08_09_53_15_globalDocking_7_SAVE_ALL_OUT_406840_18_0_0

thanks for alerting us on this. I'll see what's going on.

Why revive this thread? Anyway, the server status is showing everything is disabled except for one process. Not sure why the "Disabled" boxes are green, since it obviously isn't an all-systems-go status, but...

Seems like rosetta@home is a good project if you don't care much. Obviously I've given up caring, but I still wonder if the shadow extends to the results. I'd be a bit troubled if someone asked me to review a research paper under the condition of not caring much about the calculated results.

---

#1 Freedom = (Meaningful - Constrained) Choice{5} != (Beer^3 | Speech)

Why revive this thread? Anyway, the server status is showing everything is disabled except for one process. Not sure why the "Disabled" boxes are green, since it obviously isn't an all-systems-go status, but...

Seems like rosetta@home is a good project if you don't care much. Obviously I've given up caring, but I still wonder if the shadow extends to the results. I'd be a bit troubled if someone asked me to review a research paper under the condition of not caring much about the calculated results.

Coincidentally one of our servers had a very high load so we looked into that and decided to reboot the server which is why the project was disabled momentarily during the reboot. It seems ok now but I have to check further. This coincided with a researcher submitting over 20,000 individual unique jobs all at once which was the likely culprit for the load due to the enormous amount of files associated with so many unique jobs.

Why revive this thread? Anyway, the server status is showing everything is disabled except for one process. Not sure why the "Disabled" boxes are green, since it obviously isn't an all-systems-go status, but...

Seems like rosetta@home is a good project if you don't care much. Obviously I've given up caring, but I still wonder if the shadow extends to the results. I'd be a bit troubled if someone asked me to review a research paper under the condition of not caring much about the calculated results.

Coincidentally one of our servers had a very high load so we looked into that and decided to reboot the server which is why the project was disabled momentarily during the reboot. It seems ok now but I have to check further. This coincided with a researcher submitting over 20,000 individual unique jobs all at once which was the likely culprit for the load due to the enormous amount of files associated with so many unique jobs.

I'll ask the researcher to describe her work here on the forum. As more of our research may involve this kind of huge number of unique jobs for protein design, we will have to look into our hardware options for the upgrade we are planning to support this.

Why revive this thread? Anyway, the server status is showing everything is disabled except for one process. Not sure why the "Disabled" boxes are green, since it obviously isn't an all-systems-go status, but...

Seems like rosetta@home is a good project if you don't care much. Obviously I've given up caring, but I still wonder if the shadow extends to the results. I'd be a bit troubled if someone asked me to review a research paper under the condition of not caring much about the calculated results.

Coincidentally one of our servers had a very high load so we looked into that and decided to reboot the server which is why the project was disabled momentarily during the reboot. It seems ok now but I have to check further. This coincided with a researcher submitting over 20,000 individual unique jobs all at once which was the likely culprit for the load due to the enormous amount of files associated with so many unique jobs.

This issue has returned for just two of my tasks. Later tasks are uploading fine, but two persist in being unable to upload.

---

Three tasks stuck.

---