its a completely different issue than what started the thread, but now there's this new problem.

That problem is something the developers are aware of and they can't fix it in the present 5.10 range. It'll have to wait for BOINC 6. Sorry.

edit: it's not confined to LHC only. Multiple projects have this problem with the application restarting.

---

yup, worked for me, too.
so, what now? get rid of the wu?

Why not wait until the server comes back up. The LHC web-site displays the "down for maintenance" page. I've got 23.5 hrs into the WU I'm trying to upload. No way do I want to lose credit for that.

Would suspending the LHC project prevent attempts by LHC to communicate to the server if network connection was reestablished in the activity drop-down menu?

Would suspending the LHC project prevent attempts by LHC to communicate to the server if network connection was reestablished in the activity drop-down menu?

No. As long as there's work to upload, suspending LHC or setting it to No new tasks won't work. The upload will try to continue, contact the scheduler, crash BOINC.

Suspending network activity prevents everything from uploading/downloading/reporting.

The problem is that we don't know for how long LHC is down. We don't even know why it's down. Could be they return in an hour, a day, a week. So teh suspending of network activity is only of temporary use, especially if you're connected to multiple projects.

---

its a completely different issue than what started the thread, but now there's this new problem.

That problem is something the developers are aware of and they can't fix it in the present 5.10 range. It'll have to wait for BOINC 6. Sorry.

edit: it's not confined to LHC only. Multiple projects have this problem with the application restarting.

Roger, copy that. But Duuuuuuuude, why am I ONLY having that problem with LHC? I concede that I've heard what you say about the DLL init error problem, but I DON'T see the problem with any other BOINC client (EVER). They run flawlessly.

Quite frankly, the problem strikes as a priority issue. It seems to behave akin to setting Spybot's scan priority to high (I lose control of the system for inordinate amounts of time).

But Duuuuuuuude, why am I ONLY having that problem with LHC?

If we knew that... the problem would be easily fixed.

Why does it happen on some systems and not on others? Why only for some projects and not others? Why is rain wet and snow cold? um... ;-)

---

Would suspending the LHC project prevent attempts by LHC to communicate to the server if network connection was reestablished in the activity drop-down menu?

No. As long as there's work to upload, suspending LHC or setting it to No new tasks won't work. The upload will try to continue, contact the scheduler, crash BOINC.

Suspending network activity prevents everything from uploading/downloading/reporting.

The problem is that we don't know for how long LHC is down. We don't even know why it's down. Could be they return in an hour, a day, a week. So teh suspending of network activity is only of temporary use, especially if you're connected to multiple projects.

BUMMMERS.

Well, my earliest deadline is 08 Apr 3 0539. The worst part is I've a Lattice Project WU download transfer pending. I'll sacrifice obtaining WU's as opposed to sacrificing credit for WU completed.

Thanks for your feedback.

I have a how to in this thread.
Read it all first, please.
If you have questions, do ask.
If you don't want to try it, then don't try it.

---

well, if lhc doesn't come back online soon, i'll have to remove the wu 'cause i'm running out of work ;-)
ok, i'll see you tomorrow
ageless, thx a lot for your help

Anybody who can reproduce this crash on Linux, could you get me access to a ssh account on the machine having the problem? I can't reproduce the crash myself, but I progressed a bit in trying to find the cause. I think curl_multi_remove_handle is being passed an invalid handle.

---

I have this problem and found out something strange:

sched_reply_lhcathome.cern.ch_lhcathome.xml contains a web page instead of a scheduler reply xml document.

I used wireshark to find out which request causes this:

My computer does a "POST /lhcathome_cgi/cgi HTTP/1.1" request on "lhcathome.cern.chrn" and receives a "HTTP/1.1 301 Moved Permanently"

which contains (among a lot of other HTML) the message "The document has moved <a href="http://lhcathome.cern.ch/">here</a>"

The BOINC client then does a "Get /" on that URL and I think the result is stored in the sched_reply...xml file.

The reason is that LHC is currently down for maintenance, but this should not cause the reply XMLs to contain semi-garbage...

My computer does a "POST /lhcathome_cgi/cgi HTTP/1.1" request on "lhcathome.cern.chrn" and receives a "HTTP/1.1 301 Moved Permanently"

which contains (among a lot of other HTML) the message "The document has moved <a href="http://lhcathome.cern.ch/">here</a>"

The BOINC client then does a "Get /" on that URL and I think the result is stored in the sched_reply...xml file.

Wow. HTTP specification says a 301 Moved Permanently is supposed to keep the same method. I can't believe curl is doing that wrong.

---

LHCs scheduler is running again.

---

LHCs scheduler is running again.

Doesn't seem to be.

---

hi
i set user_network_request back to 2, started the client and everything went fine.
seems like they fixed the problem at lhc.