For those that are still having issues with your boinc client not getting the new scheduler url from our master url and if you would rather not detach and reattach the project which should fix the issue if updating doesn't. You can do the following:

1. stop the boinc client.
2. manually edit the client_state.xml, client_state_prev.xml, and master_boinc.bakerlab.org_rosetta.xml files in the BOINC client data directory by changing all occurrences of "http://boinc.bakerlab.org/rosetta_cgi/cgi" to "http://srv4.bakerlab.org/rosetta_cgi/cgi". This should be between <scheduler> and </scheduler> tags. You might not need to update master_boinc.bakerlab.org_rosetta.xml but you might as well.

If anyone has any suggestions or ideas for an easier fix, I'm all ears. The redirection does not appear to work so I removed it.

Mod.Sense suggested a quick fix for this by using the Redirect directive on our webserver. The main question now is does the client handle redirects so please let me know if this fixes the issue or not.

Thanks Mod.Sense!

Task reported too late to validate ?????

Here are two tasks submitted by a new machine I just brought up. It's a slightly older 2.34 GLIBC machine using 5.8.16 for a client (All the newer ones want GLIBC 2.4+)

The task was obtained, crunched and submitted the next day without any abort or error indicated in the STDOUT.. But with 0.00 credit ??? (The machine is only crunching Rosetta at this point).

What is up with this ?? ... Could it be the machine ?? This is the first time I have seen this one... (and ... yes, the clocks are synchronized by NTP, so TOD should not be an issue)

http://boinc.bakerlab.org/rosetta/result.php?resultid=182943687

stderr out

<core_client_version>5.8.16</core_client_version>
<![CDATA[
<stderr_txt>
# cpu_run_time_pref: 43200
======================================================
DONE :: 1 starting structures 43113 cpu seconds
This process generated 84 decoys from 84 attempts
======================================================

BOINC :: Watchdog shutting down...
BOINC :: BOINC support services shutting down...
called boinc_finish

</stderr_txt>
]]>

Validate state Task was reported too late to validate
Claimed credit 155.951746654641
Granted credit 0
application version 1.32

http://boinc.bakerlab.org/rosetta/result.php?resultid=182943208

stderr out

<core_client_version>5.8.16</core_client_version>
<![CDATA[
<stderr_txt>
# cpu_run_time_pref: 43200
======================================================
DONE :: 1 starting structures 42875.1 cpu seconds
This process generated 123 decoys from 123 attempts
======================================================

BOINC :: Watchdog shutting down...
BOINC :: BOINC support services shutting down...
called boinc_finish

</stderr_txt>
]]>

Validate state Task was reported too late to validate
Claimed credit 155.091236560251
Granted credit 0
application version 1.32

--

The processes stay running, at or near 100% finished and continue until an abort, restart or deadline. Further, a restart will either finish without recrunching the last decoy or will start the last one over with (most likely) the same hang at or near 100%..

This is accomplished with the CPU/CORE index dropping to zero, but, with the condition that BOINC is unable to assign any other crunching job to the CPU/CORE. That core becomes useless, with the exception of handling system overhead.

The watchdog process is either unable to correct the issue or fails to recognize that there is an issue.

I will open up a system to more jobs (I had discontinued all my Rosetta crunching) to see if I can capture any more information about this.

I agree that this would be a difficult one to track since the problem only shows in aborted jobs or, in the case of a successful restart intervention, a completed job.

Looked at my multi-core AMD machine (64-bit Linux client) and saw that four cores were idle. In each case, the WU had "completed" (that is, had used up as much as it should of the time allocated), but had FAILED to tell the BOINC client that the task was done. As a result, the BOINC client kept that task dispatched on a CPU core -- but since the task had finished; the corresponding core was idle. [Boincmgr showed 100% complete for these tasks, and showed that these "running" tasks were NOT accumulating any more CPU time.] Unfortunately, the only way I had to get my CPUs running again was to abort these tasks (and that in turn caused their results to be thrown away -- my system had crunched these tasks uselessly).

I've encountered this failure before with Rosetta - but that was on a different hardware system, then using the 32-bit Linux client. My conclusion is that there is a problem (at least on multi-core hardware running Linux) with how the Rosetta executable notifies the BOINC client that an application's workunit has finished.

Myself as well. I am seeing a lot of these. It does not seem to matter what the processor is, but, seems to be happening on the CASP8 tasks. Any reason that CASP8 is being run on a BETA version???

I will be aborting about a dozen units here in a few minutes.

Looked at my multi-core AMD machine (64-bit Linux client) and saw that four cores were idle. In each case, the WU had "completed" (that is, had used up as much as it should of the time allocated), but had FAILED to tell the BOINC client that the task was done. As a result, the BOINC client kept that task dispatched on a CPU core -- but since the task had finished; the corresponding core was idle. [Boincmgr showed 100% complete for these tasks, and showed that these "running" tasks were NOT accumulating any more CPU time.] Unfortunately, the only way I had to get my CPUs running again was to abort these tasks (and that in turn caused their results to be thrown away -- my system had crunched these tasks uselessly).

I've encountered this failure before with Rosetta - but that was on a different hardware system, then using the 32-bit Linux client. My conclusion is that there is a problem (at least on multi-core hardware running Linux) with how the Rosetta executable notifies the BOINC client that an application's workunit has finished.

--
*CAUTION* Since I originally posted this I had a few weird aborts. Maybe this should be ignored ... If I figure out exactly what happened I will post the issue *CAUTION*

Another thing... while your client is down....

If you are adept with a text editor, you can edit the client_state.xml and change the 5.90 version references to 5.91.

Just search for '590' It will find lines like:
<version_num>590</version_num>

for these change the 590 to 591.

Then search for 5.90 It will find lines like:
<file_name>rosetta_beta_5.90_i686-pc-linux-gnu</file_name>

change the .90 to .91

One *CAVEAT* ::: the 5.90 search will also find lines like:
<url>http://boinc.bakerlab.org/rosetta/download/rosetta_beta_5.90_i686-pc-linux-gnu</url>

*Just leave these alone*

Restart the client and 5.91 will be substituted for the 5.90... I don't know what would happen should you don this in the middle of a run, but, since, the alternative could be aborting the process.....

I am not sure I would do it.

What I would do if I were at Rosetta is re-run all of the Linux 5.90 processes just to be sure that the results are valid. I know about CRC's and checksums, but, I would rather not find out like Intel found out about the bug in the IEEE math processors of yore.... IIIIEEEEEEE!!!!

Of course your mileage may vary...