I've just had a look at your computers. Do you realise that E@H thinks you have over 6000 of them - all identical by the look of it. The first two in the list have done work and one has a fairly large list of work units that don't seem to be being processed at all.
The other 6000 odd have been created between about June 12 and June 14 and seem to have consumed about 6000 consecutive CPUIDs - it's a bit hard to tell because your list is sooooo looooooong and they are in some sort of repeating pattern rather than consecutive listing :).
Each of the 6000 odd CPUs claims to have a single work unit but I suspect that you actually don't have any of these (and the associated large data files) unless you have some terabyte sized disks :).
Something has gone drastically wrong and I guess there will be 6000 odd trashed Work Units that will have to be resent. I guess one of the developers should really have a look into what happened and why. Maybe you should post any additional information that might be of use in diagnosing this one. Hopefully nobody will blame you as the system shouldn't be able to do something like this so there must be some wierd bug to be found. Actually you'll probably get into the Guiness Book of Records for the most rapid CPUID creation of any DC project, or better still for having potentially the biggest single DC "Farm" that ever existed :).
Man, I'm glad I don't have your electricity bill!!! :).
First of all, the message that BOINC cannot write the config file is probably due to a change of the permissions of the working directory (eg C:\Program Files\BOINC on windows). So check that.
Then there was a problem with the BOINC client (already fixed, we hope) where it would try to connect again every 13 seconds, creating a new host entry each time.
As a result of this we had an account with almost 80,000 computers.
The bug should be fixed so that if the CC cannot write to the directory after trying twice then it should exit.
So things to check: 1) permissions on the working directory 2) latest core client
First of all, the message that BOINC cannot write the config file is probably due to a change of the permissions of the working directory (eg C:Program FilesBOINC on windows). So check that.
Then there was a problem with the BOINC client (already fixed, we hope) where it would try to connect again every 13 seconds, creating a new host entry each time.
As a result of this we had an account with almost 80,000 computers.
The bug should be fixed so that if the CC cannot write to the directory after trying twice then it should exit.
So things to check: 1) permissions on the working directory 2) latest core client
When it fails, why can't it (boinc) check to make sure its a security problem? Getlasterror should return a code indicating ERROR_ACCESS_DENIED. If thats the error, then BOINC should issue an "access denied" message and then exit. And thats easy to check at startup. (which is usually where you get this, its not something that happens after working for awhile unless someone intentionally changed permissions).
Thats to distinguish between permissions problems and because "another task" temporarily is using the file. That happens a lot when the indexing service, virus scanners and file backups are running. Then the error returned is ERROR_SHARING_VIOLATION.
what is error can not wright to state file
)
It means that for some reason the daemon cannot write to the client_state.xml file. There are a few possible explanations.
The user running the software does not have write rights to the BOINC tree.
Some othe process has the client_state.xml file open. (BOINCView in direct mode sometimes does this).
There are two copies of boinc.exe running. One has it open and the other cannot open it.
There is the possiblility that I missed something.
BOINC WIKI
The Wiki may have more
)
The Wiki may have more reasons
Link to Unofficial Wiki for BOINC, by Paul and Friends
RE: The Wiki may have more
)
thank you all four help on this.may have to uninstal and reinstall hope this takes care of this.
I've just had a look at your
)
I've just had a look at your computers. Do you realise that E@H thinks you have over 6000 of them - all identical by the look of it. The first two in the list have done work and one has a fairly large list of work units that don't seem to be being processed at all.
The other 6000 odd have been created between about June 12 and June 14 and seem to have consumed about 6000 consecutive CPUIDs - it's a bit hard to tell because your list is sooooo looooooong and they are in some sort of repeating pattern rather than consecutive listing :).
Each of the 6000 odd CPUs claims to have a single work unit but I suspect that you actually don't have any of these (and the associated large data files) unless you have some terabyte sized disks :).
Something has gone drastically wrong and I guess there will be 6000 odd trashed Work Units that will have to be resent. I guess one of the developers should really have a look into what happened and why. Maybe you should post any additional information that might be of use in diagnosing this one. Hopefully nobody will blame you as the system shouldn't be able to do something like this so there must be some wierd bug to be found. Actually you'll probably get into the Guiness Book of Records for the most rapid CPUID creation of any DC project, or better still for having potentially the biggest single DC "Farm" that ever existed :).
Man, I'm glad I don't have your electricity bill!!! :).
Cheers,
Gary.
Okay, I've had this problem
)
Okay, I've had this problem too.
First of all, the message that BOINC cannot write the config file is probably due to a change of the permissions of the working directory (eg C:\Program Files\BOINC on windows). So check that.
Then there was a problem with the BOINC client (already fixed, we hope) where it would try to connect again every 13 seconds, creating a new host entry each time.
As a result of this we had an account with almost 80,000 computers.
The bug should be fixed so that if the CC cannot write to the directory after trying twice then it should exit.
So things to check: 1) permissions on the working directory 2) latest core client
- Eric Myers
RE: Okay, I've had this
)
When it fails, why can't it (boinc) check to make sure its a security problem? Getlasterror should return a code indicating ERROR_ACCESS_DENIED. If thats the error, then BOINC should issue an "access denied" message and then exit. And thats easy to check at startup. (which is usually where you get this, its not something that happens after working for awhile unless someone intentionally changed permissions).
Thats to distinguish between permissions problems and because "another task" temporarily is using the file. That happens a lot when the indexing service, virus scanners and file backups are running. Then the error returned is ERROR_SHARING_VIOLATION.