"Bunsen" wrote:

...
Hmm, no. For me, the problem recurred repeatedly all the time that I *wasn't* dialled in, roughly once per minute (since the manager repeated its connection attempt with a 1-minute delay). The problem *stopped* as soon as the connection was established. I don't recall seeing any occurrences of the problem between when I connected and when I logged off.

Nicolas found a bug which sounds like it could be the culprit:

http://boinc.berkeley.edu/dev/forum_thread.php?id=1632&nowrap=true#8819

"Nicolas" wrote:

There is a network-related problem that can cause this.

BOINC recently switched to using synchronous DNS resolving, in an attempt to workaround a DNS cache bug. That means the core client can't do anything while it's waiting for the DNS to respond; it's essentially hanged until it gets a reply. If the DNS server is not replying, for example, if your internet connection has problems, it takes a relatively long time (say 30 seconds) for it to finally give up. During this period, the science app can't communicate with the core client (as the core client is "hanged", it can't reply). It may quit with the error "No heartbeat from core client for 30 seconds, exiting".

When the core client finally gets either a reply from the DNS server, or a timeout, and starts being able to do other things, it notices the science applications had suddenly disappeared. So it gives the error "Task [name] exited with zero status but no 'finished' file. If this happens repeatedly you may need to reset the project." That's the part where the clueless user follows instructions, resets project, and makes the project lose a climate model, all because of a slow or non-working Internet connection!

Another problem this DNS thing causes is unresponsive manager. BOINC Manager has always used blocking I/O for GUI RPCs. That means the BOINC Manager can't do anything while it's waiting for the core client to respond; it's essentially hanged until it gets a reply. If the core client is hanged waiting for DNS, it can't respond to the manager, so the manager can't respond to mouseclicks. It all ends in getting a completely unresponsive GUI, all because of a slow or non-working Internet connection!

Summary: A chain of nasty events. To solve everything I point out on this message, a big lot of fixes would be needed.

Basically if there are network issues it can trash Boinc + if you're very unluckly also any work units you have running at the time. From the description the diagnostic symptom would be that the Manager appears to freeze for 30 seconds at a time.

Does it help if you 'suspend network' most of the time, and just do 'allow network' briefly once you know for certain that you're connected?

---

Does it help if you 'suspend network' most of the time, and just do 'allow network' briefly once you know for certain that you're connected?

I've been using version 5.4.11 since I got a clear idea of the nature of the problem with 5.8.x and saw how it was affecting my productivity. But I've upgraded to 5.8.15 again and I'll try this for a few days, with my automated periodic checking of the work-unit progress/status. Having to enable/disable network communication manually will be a bit of a pain, but if it can help to produce useful diagnostic information... <*shrug*>

Does it help if you 'suspend network' most of the time, and just do 'allow network' briefly once you know for certain that you're connected?

Okay, I've been doing this with 5.8.15 for the last week and a half or so. Having to enable/disable the network connectivity manually is indeed an annoyance, but I haven't had that error occur once in that time. It looks like you may have found the culprit.

I don't suppose that the problem is likely to be solved any time soon..?

That depends on the Boinc developers. I hope it's sorted soon, this is potentially a big problem for the climate projects. Because they run for so long (300-3000 hours), the platform they're running on needs to be really reliable.

Probably a good idea to go back to 5.4.11 for the time being now that your problem has been pinpointed...

---

(The above was referring to the networking-issues-causing-zero-exit problem rather than the time-sync-causing-zero-exit problem).

---

That depends on the Boinc developers. I hope it's sorted soon, this is potentially a big problem for the climate projects. Because they run for so long (300-3000 hours), the platform they're running on needs to be really reliable.

Has all of the relevant information been added to the bug database? I'm reluctant to go messing around in there myself, since I'm not involved in the development process.

That depends on the Boinc developers. I hope it's sorted soon, this is potentially a big problem for the climate projects. Because they run for so long (300-3000 hours), the platform they're running on needs to be really reliable.

Has all of the relevant information been added to the bug database? I'm reluctant to go messing around in there myself, since I'm not involved in the development process.

I'll check out the open tickets. I don't remember opening one up (as Jord and I were moving the open tickets from the old system to the new one) but that doesn't mean there's not one already open.

Please remember, BOINC is software enhanced by the community. So if you'd like to open a ticket, please go for it. You'll need to register for the Trac system. I think it's easier to use than the old BOINCZilla system.

---

Kathryn :o)

I posted it onto the Boinc_dev email list a few days ago, no idea if anyone picked it up and put it into Trac.

---

I posted it onto the Boinc_dev email list a few days ago, no idea if anyone picked it up and put it into Trac.

I must have missed it when you posted because I don't remember reading that email.

:-)

I'll open a ticket highlighting the main points and then pointing back to this thread.

[edit]Done! Ticket #113[/edit]

---

Kathryn :o)

'Twas this one, not surprising you missed it since it was in the middle of a thread (in reply to Tigher's intention to make 5.8.x mandatory for his project, which makes the workaround of downgrading to 5.4.x impossible).

http://www.ssl.berkeley.edu/pipermail/boinc_dev/2007-April/000082.html

Thanks for adding the item into Trac :-)

---

On a side note, with this 'Trac' (Is that something generic in American English?), was the CVS Check-in Notes discontinued? Nothing was added since April 16.

CVS was discontinued, the new thing to use is SVN.
For checkin-notes look here: http://boinc.berkeley.edu/trac/browser/trunk/boinc/checkin_notes

---

ARGH, I knew this bug would be a problem for the climate projects. Just lost 3 climate models (my firewall crashed and as a result internet and localhost traffic was blocked for 12 hours). All 3 models died at the same time, about 2 hours after the firewall crash happened.

I've had the firewall crash rarely before, but without ill effect (that was with 5.4.x rather than 5.8.x).

---

Has the DNS behaviour that seems to be the cause of this been fixed in 6.2? (It's in the database as http://boinc.berkeley.edu/trac/ticket/113 -- the item has been "modified" a couple of times in the last couple of months, but I haven't seen any changes in the item.)

Has the DNS behaviour that seems to be the cause of this been fixed in 6.2? (It's in the database as http://boinc.berkeley.edu/trac/ticket/113 -- the item has been "modified" a couple of times in the last couple of months, but I haven't seen any changes in the item.)

No. I very recently upgraded to 6.2.16 and the error still exists.

Funny thing is, I wasn't receiving this error at all UNTIL version 6.2.16. I had never even seen this situation, either on my old dial-up connection OR with my current broadband connection.

I posted a message to the CPDN board and received the "mostly benign" answer.

No. I very recently upgraded to 6.2.16 and the error still exists.

Funny thing is, I wasn't receiving this error at all UNTIL version 6.2.16. I had never even seen this situation, either on my old dial-up connection OR with my current broadband connection.

I posted a message to the CPDN board and received the "mostly benign" answer.

That's because it mostly is. In the case of CPDN, it happens at times and it usually goes away by itself as well.

If it happens on other projects as well, we'd be interested to know about it.
Especially since you use a single CPU computer. (So it can't be the throttling in combination with multiple CPU bug)

---