I bought a new computer and installed the latest revision (5.8.11). {I was running an older version on the previous computer.} I attached back to Seti@Home and Climateprediction.net. Both are running and calculating. But, I get the above error in messages. I 've tried resetting both projects, no help. Am I missing something very basic?? Thanks.

Jim Crawford

---

Don't reset your projects. Just let it run. It's a benign error that will go away if you let it alone.

It's to do with your Boinc Manager not being able to communicate with the Boinc client (daemon). Make sure your Boincmgr.exe and boinc,exe are allowed to communicate with each other on local system (127.0.0.1) on port 31416 in your firewall.

---

Don't reset your projects. Just let it run. It's a benign error that will go away if you let it alone.

It's to do with your Boinc Manager not being able to communicate with the Boinc client (daemon). Make sure your Boincmgr.exe and boinc,exe are allowed to communicate with each other on local system (127.0.0.1) on port 31416 in your firewall.

In my experience, it seems to be a benign (read false) error, but under BOINC 5.8.11, it won't go away. It happens every time an app is deallocated by BOIN for another app.

Jim

From the alpha list...

Yes, these are bogus (but harmless) messages.
I checked in a change that gets rid of them.
-- David

---

Kathryn :o)

Saw a note from DA that a certain 'File Not Found' was not going to printed anymore. Is this the same or a different one? I've been hibernating machines, but before suspending processing, written down the CPU times and % progress and on re-awakening checked the log and seen the zero status entries even before taking the Agent out of suspend. Checked the progress times and apparently no beat was lost or checkpoint regression taking place.

You should wait for the next release with the fix, and see if it still happens. If it does, it's a different reason.

I think David's comment only related to the rash of spurious zero status messages every time a project was paused for any reason (round-robin switch or whatever).

The original messages are still there: I've just had one, tracked down to an old-fashioned clock synchronisation.

---

"Task ... exited with zero status but no 'finished' file" Fixed with version 5.8.15

Was that meant to mean 'Not Fixed'? Upgraded to 5.8.15 2 days ago and they are still showing:

Must be a different one than to the one noted by David Anderson.

Fixed the ones I have been getting on Windows since 5.8.11 on SETI. What OS are you getting these on?

These messages may be intended to be benign, but when some crunchers DO see them repeatedly and then DO reset the project (which in my view is a logical action in the circumstances), they lose their workunit which on cpdn can mean a lot of lost work. I wish that the bit about resetting the project could be omitted.

---

I wish that the bit about resetting the project could be omitted.

The strong word in it is may. Perhaps it's better to add, "go ask at the project forum if you need to" ? Or something similar.

---

The error does not appear to be "harmless"; it appears that the
current CPU progress is reset to a smaller value when it happens.
I haven't tried digging into the code; this is based on observation
of the stats. I'm using BOINC Manager 5.8.15 on Windows XP, and I
set up a scheduled task to pull the fraction_done and current_cpu_time
values out of the client_state.xml file every 5 minutes. I'm not
sure about the fraction_done value, but the current_cpu_time is
definitely getting knocked back.

The error does not appear to be "harmless"; it appears that the
current CPU progress is reset to a smaller value when it happens.
I haven't tried digging into the code; this is based on observation
of the stats. I'm using BOINC Manager 5.8.15 on Windows XP, and I
set up a scheduled task to pull the fraction_done and current_cpu_time
values out of the client_state.xml file every 5 minutes. I'm not
sure about the fraction_done value, but the current_cpu_time is
definitely getting knocked back.

The time lost should be minimal as it should restart at the last saved checkpoint. There are projects that checkpoint infrequently, and they will be impacted to a greater extent.

---

Boinc V 7.4.36
Win7 i5 3.33G 4GB NVidia 470

The time lost should be minimal as it should restart at the last saved checkpoint. There are projects that checkpoint infrequently, and they will be impacted to a greater extent.

On my machine, over some periods, the error occurs frequently -- every few minutes, or worse. The tasks progress *very* slowly as a result, when they manage to gain a bit more ground and checkpoint before being reset. This morning, for example, I had a SETI@Home unit and an Einstein@Home unit that made *no* progress for half an hour since the projects kept getting reset every 63 seconds or so.

Hmm. According to the message log, the repeated exit-and-reset stopped when SETI@Home started asking to connect to the net to fetch work and report results. Einstein@Home had been requesting a connection for a couple of minutes before that. It was probably at about that time that I first "woke up" the computer this morning and dialed in to my ISP. I don't know which of these "state changes" might relate to the exit-and-reset stopping.

On my machine, over some periods, the error occurs frequently -- every few minutes, or worse. The tasks progress *very* slowly as a result, when they manage to gain a bit more ground and checkpoint before being reset. This morning, for example, I had a SETI@Home unit and an Einstein@Home unit that made *no* progress for half an hour since the projects kept getting reset every 63 seconds or so.

It looks rather like the bogus error-and-reset is associated with unsuccessful attempts of the manager to connect with the net, i.e. when I'm not dialed in. It doesn't *always* happen with a connection attempt, but it *only* appears to be happening when an attempt is made, and at that precise time. The "defer for 1 minute" behaviour seems to be what was causing that 63-second reset.

I've heard of network problems causing the zero-exit issue before. Incidentally, the developers are thinking of aborting work units if they get too many of these between checkpoints. So if you've been working on a CPDN workunit for a few months, and then get network problems, Boinc will abort the CPDN workunit (proposed for 5.9/5.10).

---

I've heard of network problems causing the zero-exit issue before. Incidentally, the developers are thinking of aborting work units if they get too many of these between checkpoints. So if you've been working on a CPDN workunit for a few months, and then get network problems, Boinc will abort the CPDN workunit (proposed for 5.9/5.10).

As long as they just talk about it, it's fine :P

You mean as long as they don't actually do it? hehe

I just noticed that the "exited with zero status but no 'finished' file" error also comes up when your time is set back while Boinc runs. I don't use any applications that automatically set my computer clock to the same time as the nearest atomic clock has it, but I ran one manually a moment ago.

If you do... you can run into this problem. it would also explain why it does it for people who use dial-in, that it gives this error the moment they dial-in, as that's usually the time the clock equalizes itself with whatever time server is out there. Doesn't Windows XP have such a feature?

---

Hi,

There's a page here which discusses the zero exits due to time sync and makes a couple of suggestions. XP will do the time sync every few hours, and so if the PC clock is fast, it will cause the zero exit to happen regularly while the PC is online.

http://bbc.cpdn.org/forum_thread.php?id=1573&nowrap=true#12452

There are many other things which can also cause the same 'Exit 0 status no finished file' message.

I'd guess that perhaps 0.2% of all CPU time in Boinc is lost to the time sync issue? i.e., if 1/3 of PCs have fast clocks, are connected to the internet 1/3 of the time, 3/4 are XP, the time sync occurs every 3 hours, and finally if the average time since the last checkpoint is 5 minutes.

---

it would also explain why it does it for people who use dial-in, that it gives this error the moment they dial-in, as that's usually the time the clock equalizes itself with whatever time server is out there.

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.

it would also explain why it does it for people who use dial-in, that it gives this error the moment they dial-in, as that's usually the time the clock equalizes itself with whatever time server is out there.

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.

Would it be possible Windows XP was trying to synch with the time server and that would throw off BOINC?

Thanks for the info, Mike.

---