Michael* I can't offer any suggestions. As you pointed out, suspend and resume of the task doesn't even seem to kick it to start, at least when tasks are kept in memory, so full restart of BOINC seems to be the only way to get CPU allocated to the task again. I can only confirm that others have observed this as well, and that it seems to be rather rare.

I haven't seen what happens if BOINC reschedules that task one it's own. I mean if you suspend it, it will begin another task. If you then release it, BOINC will eventually try to come back to it. At that time does it successfully get CPU time? Or does it get no CPU while BOINC still says it is running? Something to try anyway.

robertmiles On Michael*'s problem: Could that indicate that restarting from what's left in the main memory does not work adequately for that problem, but restarting from the last checkpoint on the hard drive does?

If I suspend all computation and then resume then the WUs stay in memory and it does not fix the stuck WU. Completely closing BOINC and restarting it does fix the stuck WU. I have not tried to suspend an individual stuck WU and then resume it later but I'll attempt it next time this happens. I seem to get a stuck Rosetta WU about every other day for the past couple of weeks. The only change I've made to BOINC in that time is I added a configuration file to suspend computation while a specific application is running on my PC. <exclusive_app>filename.exe</exclusive_app>

...is it possible to be corrupted while downloading.

It is possible for corruption to occur to any data that passes over a network. However, BOINC has signatures that double check the integrity of the files you receive. When a signature mismatch is found, the error is reported differently and the task is not run.

Generally the error about gzipping is due to the output file not being produced. So it isn't there to zip. And this is because the error occurred before any output was produced.

Ok thanks for the reply.

---