LHC@home

I got another Pirates as well, but tried changing the project name back in the client_state.xml. I thought it worked, but when trying to report a result back to S@H, it couldn't recognize the app version, even though it was correct in the c_s.xml file.

So I restored a four day old c_s.xml file and reset Pirates and S@H. (the apparent projects with issues) Then within an hour, all six of the projects I'm attached to thought they were LHC!

I restored the older file again and detached from LHC, and reset the other projects. All is functioning well at this point. (it might be worthwhile to know that LHC was having major connection issues at the time)

I'm attached again to LHC since others were reporting things seemed to be functioning again. All seems normal, but this hiccup trashed over 200 hours of work for CPDN alone. More counting the other projects.

I suspect the problem was with LHC, (because the connection issues started right before the first problem arose) but I'm somewhat appalled that cross project havoc can be wreaked in this manner... There needs to be checks in place to insure this can not happen again.

<a> [/url]

> [Edit]
> Now re-attached to all three projects: CPDN, Pirates, LHC. We'll see what
> happens.

I've been attached to my six original projects now for almost 4 1/2 hours, and all seems good.

I really think it had something to do with LHCs connection problems. When it was occurring, BOINC would try to contact LHC and basically hang the client for a couple minutes waiting for a reply. No other projects could communicate when this happened. A manual update would do nothing. (first thing I tried when S@H thought it was Pirates)

> @Heffed
> Indeed, major flaw to allow this kind of coruption. It's bad for both the
> user and the other projects.

I am just astonished that it could happen. I would have thought such a thing would be an obvious issue to safeguard.

> > [Edit]
> > Now re-attached to all three projects: CPDN, Pirates, LHC. We'll see
> what
> > happens.
>
> I've been attached to my six original projects now for almost 4 1/2 hours, and
> all seems good.
>
> I really think it had something to do with LHCs connection problems. When it
> was occurring, BOINC would try to contact LHC and basically hang the client
> for a couple minutes waiting for a reply. No other projects could communicate
> when this happened. A manual update would do nothing. (first thing I tried
> when S@H thought it was Pirates)
>
> > @Heffed
> > Indeed, major flaw to allow this kind of coruption. It's bad for both
> the
> > user and the other projects.
>
> I am just astonished that it could happen. I would have thought such a thing
> would be an obvious issue to safeguard.
>
I am not saying do not post these problems here but the Boinc devs need to know about this more than the LHC devs, has anybody told them about this?

> I am not saying do not post these problems here but the Boinc devs need to
> know about this more than the LHC devs, has anybody told them about this?

There are posts on the S@H board as well. Like this one that even links to this thread. How close they watch the boards I couldn't say...

<a> [/url]

> As an experiment, I detached from Pirates then attched again.

What is Pirates? Is it a valid BOINC project? When I saw the postings refering to "Pirates" I figured it was a BOINC hijacking by hackers.

regards,
Rob

> What is Pirates? Is it a valid BOINC project? When I saw the postings refering
> to "Pirates" I figured it was a BOINC hijacking by hackers.

Pirates is a test bed for Einstien@Home.

http://pirates.vassar.edu/

> > I am not saying do not post these problems here but the Boinc devs need
> to
> > know about this more than the LHC devs, has anybody told them about
> this?
>
> There are posts on the S@H board as well. Like <a> href="http://setiweb.ssl.berkeley.edu/forum_thread.php?id=4656">this one[/url]
> that even links to this thread. How close they watch the boards I couldn't
> say...
>
> <a> [/url]
>
>
Don't expect much of a response from S@H it takes them a year to acknowledge connectivity issues.

New information is 6 months old.

This a bit of a niggle but SETI@home admins do not seem to respond to their message boards. Since Jan. I only know of 3 messages being sent by the admins of the project.

But your point is valid.
But, I actually thought BOINC was another project done at Berkerely, I know SETI@home have a close relationship with BOINC people.

I have experienced the stated problem. It only occured when the LHC site went extremely slow about 10-20 bytes per second Connectivity

Sorry I am english but you never of guessed with the way I write the language.

> Argh! First one machine got nailed with this and now I've seen a second
> machine fall prey to this bug. It's definitely a problem in the core client

Now, that said, this is all really easy to fix. And, yes, I mean really easy. A couple of minutes with the editor of your choice and your projects will be back to normal. Here's how to fix it:

1) Close BOINC
2) Make back-up copies of all your XML files to a safe directory
3) Open all account_*.xml files and edit the project name so that it is appropriate to the project URL
4) Open client_state.xml. Scroll through the file. Change your project name(s) that you corrected in the account files to match the URLs here, too. Note that the XML file contains project tags for each project. When you find an affected project, you'll see that there is app and file data that is inconsistent with that project. Delete these entries (including tags) from the file. Don't be shy (you made back-ups, right?) -- you can do it again in case you mess something up. Besides, your editor has undo.
5) Delete invalid files from the project dirs
6) Restart BOINC
7) It *might* be necessary to detach an orphan project. In my first attempt, I somehow wound up with an extra LHC@home on one machine. It showed 0 results, so I just detached it. My valid LHC@home entry remains fine.

I've fixed two machines so far and both are working fine now. LHC@home seems to be offering valid work again, so maybe the hiccoughs are short-lived. I'll check (and maybe fix) my third LHC@home-enabled machine as soon as the GUI un-freezes (it's a dual that's only got work for one slot at the moment).

I hope this helps, people. Click "It answered my question" now. ;)

trane

> But I actually thought BOINC was another project done at Berkerely, I know
> SETI@home have a close relationship with BOINC people.

They are one and the same. The S@H team developed (is developing) BOINC.

> > Argh! First one machine got nailed with this and now I've seen a second
> > machine fall prey to this bug. It's definitely a problem in the core
> client
>
> Now, that said, this is all really easy to fix. And, yes, I mean really easy.
> A couple of minutes with the editor of your choice and your projects will be
> back to normal. Here's how to fix it:
>
> 1) Close BOINC
> 2) Make back-up copies of all your XML files to a safe directory
> 3) Open all account_*.xml files and edit the project name so that it is
> appropriate to the project URL
> 4) Open client_state.xml. Scroll through the file. Change your project name(s)
> that you corrected in the account files to match the URLs here, too. Note that
> the XML file contains project tags for each project. When you find an affected
> project, you'll see that there is app and file data that is inconsistent with
> that project. Delete these entries (including tags) from the file. Don't be
> shy (you made back-ups, right?) -- you can do it again in case you mess
> something up. Besides, your editor has undo.
> 5) Delete invalid files from the project dirs
> 6) Restart BOINC
> 7) It *might* be necessary to detach an orphan project. In my first attempt, I
> somehow wound up with an extra LHC@home on one machine. It showed 0 results,
> so I just detached it. My valid LHC@home entry remains fine.
>
> I've fixed two machines so far and both are working fine now. LHC@home seems
> to be offering valid work again, so maybe the hiccoughs are short-lived. I'll
> check (and maybe fix) my third LHC@home-enabled machine as soon as the GUI
> un-freezes (it's a dual that's only got work for one slot at the moment).
>
> I hope this helps, people. Click "It answered my question" now. ;)
>
> trane
>
>
>
Once the the LHC project are deleted form the other project folders.
clicking update normally remedies the project name.
But for this to work you need conectiviy to the project (This is not always the case)