6 tasks failing at various points in their process- need help
27 Dec 2012 18:52:58 UTC
Topic 196708
(moderation:
I am getting this message in some of the tasks listed below:
7.0.28
The system cannot find the file specified. (0x2) - exit code 2 (0x2)
Activated exception handling...
[18:14:00][8872][INFO ] Starting data processing...
[18:14:00][8872][INFO ] Checkpoint file unavailable: status.cpt (No such file or directory).
------> Starting from scratch...
[18:56:23][3648][INFO ] Checkpoint committed!
[18:57:35][3648][ERROR] Couldn't rename temporary checkpoint file (status.cpt.tmp) to final checkpoint file: status.cpt (No such file or directory).
[18:57:36][3648][ERROR] Demodulation failed (error: 2)!
18:57:37 (3648): called boinc_finish
The following tasks contain this error: (no problems with firewall already checked there)
http://einsteinathome.org/task/329880760
http://einsteinathome.org/task/328949166
http://einsteinathome.org/task/328946541
http://einsteinathome.org/task/328928600
and 4 more just like this
the person before me completed the task ok, as did the one after me. but for some reason I can not complete these due to that missing file.
Anyone got an idea as to what is happening?
6 tasks failing at various points in their process- need help
)
Does your BOINC client have the appropriate rights (write/create) in your BOINC data directory and its subdirectories?
Or does your AV program intervene when the client creates files there?
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
i just had a few more error
)
i just had a few more error out.
checked AV, can not find any problem, but setup a exception for the drive that boinc is stored on. there must be something in the code of the binary radio pulsar p2030 tasks that is causing the AV to act up. I am using immunet av.
but what I don't get is that other Einstein tasks do not trigger this AV issue nor do tasks from Milkway, Poem or Rosetta. very weird.
will monitor the next binary task that is queued.
RE: [18:56:23][3648][INFO ]
)
The above is the critical excerpt from your log.
Checkpoints are the saved state of the crunching process from which crunching can be restarted whenever necessary. They are created and saved at regular intervals. They allow BOINC to be stopped with minimal loss of what has already been crunched for a given task.
When a new checkpoint is to be written, there has to be protection against the possibility of something going wrong at the critical moment when the new checkpoint is replacing the old one. So the new one is written first (with a temporary name) before the old one is deleted. Later on it can be renamed to the proper name.
Your log shows a successful checkpoint being saved at 18:56:23. A bit over a minute later BOINC thought it had created the next checkpoint (with a temporary name) but then it couldn't find the file when it came time to rename it to the proper name. The most likely reason for this would probably be that your security software happened to catch this event and decided to prevent the tmp file from actually being written. It can't be a permissions problem because the previous checkpoint was successfully written.
I'm guessing that you just need to stop whatever is interfering with BOINC's normal activities.
Cheers,
Gary.
Problem solved by creating an
)
Problem solved by creating an exemption for the partition that boinc resides on. since that time there have been no further problems with p2030 tasks. Seems there is something in the coding of those tasks at a certain point that the AV software does not like. Very strange since other tasks before that were ok. But that could be due to the way the coding is written for the AV software. In any case problem solved with the suggestion of Gundolf.