I have been unable to connect to the server for close to a week now. All I get is the HTTP internal server error; Project communication failed; Internet access OK: project servers may be temporarily down; Scheduler request failed:attempting access to reference site.

Am I out of luck with my application now because of the changes that Seti@Home has made? When I was able to get WU's last, I got the invalid app error.

I run a legacy operating system. We only have the one application that has ever been written for it. Is the problem of older application version in the app_info.xml file the reason I can no longer communicate with the project?

I also recently installed a Ubuntu Linux system onto this computer and have been switching between the OS's occasionally. When I booted into the Linux system, it had no problems getting new work after the servers came back online.

Is there anything I can do to correct the issue on my end with the eComStation application? Can I edit something in the app_info.xml file that will fix it and not break the application further. Can I spoof some other version of the application to make Seti believe I am running a more recent version of the application?

Cheers, Keith

You could post your app_info, but when i looked at your host's, your OS/2 machine had just reported successfully, and got work twice,

Claggy

Hey guys and girls,

Sorry i haven't been around much. Been busy working on some web servers for a company.

Anyway.. After having these same issues i did some debugging.

Noticed that the URL boinc tries to connect to is initiating a request on port 80 (http) so naturally that means apache or something is installed on that server.

Tried accessing http://setiboinc.ssl.berkeley.edu or even http://ssl.berkeley.edu a few times over an hour, i got 4 successful requests which returned the default fedora test page. And the rest were not successful.

"The server at http://setiboinc.ssl.berkeley.edu is taking too long to respond."

This means boinc cannot communicate with it either. Now i'm not sure if it's some sort of network issue and why it's only affecting a few people and not others. But i know one thing, it's certainly an issue with the server running the scheduler since obviously it's inaccessible a large amount of the time.

I have a feeling either there is an issue with the web server setup or a routing issue somewhere, if they use NFS maybe something isn't working right between communication of the schedule servers and database servers.

Just thought i should let you know, since although there have been a few fixes listed here, none of these /should/ in theory be actually fixing anything as the problem lies with the connection to that URL.

---

- Jarryd

@Hellsheep, solving the "can not connect error" is indeed beyond our control (apart from retrying over and over ;)) However the "HTTP internal server error" is returned by the server. So in those cases the connection did succeed. This error is found to be related to a reference in onces app_info.xml file to the old AP version. Appearantly the update to the server sided software on July the 26th does not take into account that reference anymore.

Since this is a referal to an optimized application on the windows platform, only those clients who installed that particular version of the optimized client are affected.
Removing the entry for optimized AP versions other then v505 will solve it for now.

---

@Hellsheep, solving the "can not connect error" is indeed beyond our control (apart from retrying over and over ;)) However the "HTTP internal server error" is returned by the server. So in those cases the connection did succeed. This error is found to be related to a reference in onces app_info.xml file to the old AP version. Appearantly the update to the server sided software on July the 26th does not take into account that reference anymore.

Since this is a referal to an optimized application on the windows platform, only those clients who installed that particular version of the optimized client are affected.
Removing the entry for optimized AP versions other then v505 will solve it for now.

If that is the case then why are those clients without any old version entries also having the same connection problems?

---

If that is the case then why are those clients without any old version entries also having the same connection problems?

Because it's a problem with the servers, not related to any software versions you may have on your system.
The fact that some systems have been unable to connect at all while many can would indicate a DNS issue of some sort, but the fact is even if you do make contact, it could take 5 or more attempts before you make a successful connection, and even then things still may not work.

---

Grant
Darwin NT

@Hellsheep, solving the "can not connect error" is indeed beyond our control (apart from retrying over and over ;)) However the "HTTP internal server error" is returned by the server. So in those cases the connection did succeed. This error is found to be related to a reference in onces app_info.xml file to the old AP version. Appearantly the update to the server sided software on July the 26th does not take into account that reference anymore.

Since this is a referal to an optimized application on the windows platform, only those clients who installed that particular version of the optimized client are affected.
Removing the entry for optimized AP versions other then v505 will solve it for now.

Hosts that ran the Stock Astropulse or Stock Astropulse_v5 app may be affected as well, as their client_state file may still have the reference to Astropulse or Astropulse_v5,

Claggy

There's two different problems here:

a) a general connectivity issue i.e. difficulties to connect for everybody getting through only part of the time

b) a host specific 'unable to connect at all' issue, that has been traced to app_infos containing old (no longer supported) application data, probably due to some server side change. This problem can be resolved by removing blocks refering to old applications from app_info.

---

Carola
-------
I'm multilingual - I can misunderstand people in several languages!

Well....
I would debate the effect of anything in the app_info.
All 4 of my crunchers are running the exact same Lunatics installed optis and app_infos....
And have been able to connect and report work most of the time.

I just tried a manual update on the Frozen 920, and got the can't connect to server error twice in 10 minutes trying to report 41 completed tasks.

Watching the NIC status lights, I can see Boinc trying to get the server, but the server never answers. So whatever is in my app_info isn't even coming into play. And this with the Cricket graphs showing slightly declining traffic all day....

The problem is not with my television set.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Well....
I would debate the effect of anything in the app_info.
All 4 of my crunchers are running the exact same Lunatics installed optis and app_infos....
And have been able to connect and report work most of the time.

I just tried a manual update on the Frozen 920, and got the can't connect to server error twice in 10 minutes trying to report 41 completed tasks.

Watching the NIC status lights, I can see Boinc trying to get the server, but the server never answers. So whatever is in my app_info isn't even coming into play. And this with the Cricket graphs showing slightly declining traffic all day....

The problem is not with my television set.

It depends on the messages you see in BOINC Manager.

As Carola says, there are two quite distinct problems:

a) If you see a general grumbling about 'HTTP service unavailable', 'Couldn't connect to server', 'Project has no tasks available' (those seem to be the main ones on this machine today), then indeed "Do not adjust your set", the TV is OK, it's the servers which are struggling.

but...

b) If you see the specific message "HTTP Internal Server error", check that your app_info.xml file is really as clean as you think it is.

The Frozen 920's app_info references 603, 608, and 505.

About 3 hours ago in the log I see.....server returned nothing (no headers, no data). And it is littered with can't connect errors all day long.


EDIT...
And it did just connect on it's own and reported those completed WUs.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Removing the references to the obsolete applications from my app_info.xml solved this issue for me. The next update completed succesfully and my wu's are reported.

Woohoo!! worked a treat, All have now reported. Perhaps i can now get a good nights sleep.

Many thanks

dlanor

---

It depends on the messages you see in BOINC Manager.

but...

b) If you see the specific message "HTTP Internal Server error", check that your app_info.xml file is really as clean as you think it is.

I cleared my app-Info.xml, but still getting the HTTP Internal Server Error.

2-8-2010 0:07:28 SETI@home update requested by user
2-8-2010 0:07:30 SETI@home Sending scheduler request: Requested by user.
2-8-2010 0:07:30 SETI@home Reporting 11 completed tasks, requesting new tasks
2-8-2010 0:08:44 SETI@home Scheduler request failed: HTTP internal server error

Could some one check my xml and tell me weather it is correct or not?

<app_info>
    <app>
        <name>astropulse_v505</name>
    </app>
    <file_info>
        <name>ap_5.05r168_SSE.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>astropulse_v505</app_name>
        <version_num>505</version_num>
        <file_ref>
            <file_name>ap_5.05r168_SSE.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <app>
        <name>setiathome_enhanced</name>
    </app>
    <file_info>
        <name>AK_v8_win_SSE2.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>603</version_num>
        <file_ref>
           <file_name>AK_v8_win_SSE2.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
</app_info>

---

Goodbye Seti Classic

It depends on the messages you see in BOINC Manager.

but...

b) If you see the specific message "HTTP Internal Server error", check that your app_info.xml file is really as clean as you think it is.

I cleared my app-Info.xml, but still getting the HTTP Internal Server Error.

2-8-2010 0:07:28 SETI@home update requested by user
2-8-2010 0:07:30 SETI@home Sending scheduler request: Requested by user.
2-8-2010 0:07:30 SETI@home Reporting 11 completed tasks, requesting new tasks
2-8-2010 0:08:44 SETI@home Scheduler request failed: HTTP internal server error

Could some one check my xml and tell me weather it is correct or not?

<app_info>
        <name>astropulse_v505</name>
    </app>
    <file_info>
        <name>ap_5.05r168_SSE.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>astropulse_v505</app_name>
        <version_num>505</version_num>
        <file_ref>
            <file_name>ap_5.05r168_SSE.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <app>
        <name>setiathome_enhanced</name>
    </app>
    <file_info>
        <name>AK_v8_win_SSE2.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>603</version_num>
        <file_ref>
           <file_name>AK_v8_win_SSE2.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
</app_info>

Looks fine to me....only 603 and 505, both of which should be fine.

Which confirms to me that the problem is within the Seti servers, and may have little to do with the condition of one's app_info file.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

It depends on the messages you see in BOINC Manager.

but...

b) If you see the specific message "HTTP Internal Server error", check that your app_info.xml file is really as clean as you think it is.

I cleared my app-Info.xml, but still getting the HTTP Internal Server Error.

2-8-2010 0:07:28 SETI@home update requested by user
2-8-2010 0:07:30 SETI@home Sending scheduler request: Requested by user.
2-8-2010 0:07:30 SETI@home Reporting 11 completed tasks, requesting new tasks
2-8-2010 0:08:44 SETI@home Scheduler request failed: HTTP internal server error

Could some one check my xml and tell me weather it is correct or not?

<app_info>
    <app>
        <name>astropulse_v505</name>
    </app>
    <file_info>
        <name>ap_5.05r168_SSE.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>astropulse_v505</app_name>
        <version_num>505</version_num>
        <file_ref>
            <file_name>ap_5.05r168_SSE.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
    <app>
        <name>setiathome_enhanced</name>
    </app>
    <file_info>
        <name>AK_v8_win_SSE2.exe</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome_enhanced</app_name>
        <version_num>603</version_num>
        <file_ref>
           <file_name>AK_v8_win_SSE2.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>
</app_info>

Looks clean to me. What were the startup messages, when you restarted after the edit?

Looks fine to me....only 603 and 505, both of which should be fine.

Which confirms to me that the problem is within the Seti servers, and may have little to do with the condition of one's app_info file.

There was an error in my app_info file.
After adding <app> right after the first <app_info>, restarting BOINCmanager and trying to update 4 times, suddenly the wu's were reported, and new wu's were downloaded.

Thanks BuddyWolly for this work-aroud.

---

Goodbye Seti Classic

Looks fine to me....only 603 and 505, both of which should be fine.

Which confirms to me that the problem is within the Seti servers, and may have little to do with the condition of one's app_info file.

There was an error in my app_info file.
After adding <app> right after the first <app_info>, restarting BOINCmanager and trying to update 4 times, suddenly the wu's were reported, and new wu's were downloaded.

Thanks BuddyWolly for this work-aroud.

Ah, I thought I saw a difference between Mark's quote and my quote of ostensibly the same message. If you've posted asking for help, and subsequently edit the data you're asking about, it would be helpful to mention the edit in a footnote.

Anyway, glad you worked it out in the end.

Ah, I thought I saw a difference between Mark's quote and my quote of ostensibly the same message. If you've posted asking for help, and subsequently edit the data you're asking about, it would be helpful to mention the edit in a footnote.

Anyway, glad you worked it out in the end.

You are right, sorry for that.

But there still seems to be another problem:

2-8-2010 0:42:28 SETI@home Requesting new tasks
2-8-2010 0:42:31 SETI@home Finished download of 29my10aa.7594.15883.16.10.202
2-8-2010 0:42:31 SETI@home Finished download of 24my10ab.28183.11267.12.10.70
2-8-2010 0:43:03 SETI@home Scheduler request completed: got 0 new tasks
2-8-2010 0:43:03 SETI@home Message from server: No work sent
2-8-2010 0:43:03 SETI@home Message from server: This computer has reached a limit on tasks in progress
2-8-2010 0:43:18 SETI@home Sending scheduler request: To fetch work.
2-8-2010 0:43:18 SETI@home Requesting new tasks
2-8-2010 0:43:41 Project communication failed: attempting access to reference site
2-8-2010 0:43:41 SETI@home Scheduler request failed: Failure when receiving data from the peer
2-8-2010 0:43:42 Internet access OK - project servers may be temporarily down.

---

Goodbye Seti Classic

Ah, I thought I saw a difference between Mark's quote and my quote of ostensibly the same message. If you've posted asking for help, and subsequently edit the data you're asking about, it would be helpful to mention the edit in a footnote.

Anyway, glad you worked it out in the end.

You are right, sorry for that.

But there still seems to be another problem:

It's OK.

Yes, exactly: there are two problems, as we've discussed before in this thread.

You've fixed the one which is fixable at your end. Great stuff.

Now you're left with the other one, the one which is only fixable at the server end. But that one is at least intermittent: if you leave it running overnight, there's a fair chance that at some point you'll get the work you're asking for. With the app_info error, you had no chance at all.

Well, I don't know if my futzing with the app_info.xml did anything or not. The client has been running for days now with no success connecting. Just after I made my post, I figured what the heck and edited the app_info.xml file and removed the AstroPulse 4.28 application which I never could run anyway. Then I left for town to go to the bank. Just now looked at the computer and see that it was successful in reporting my 5 finished WU's and successfully downloaded new work. So either, removing the AstroPulse application reference either worked or finally Seti finally let me connect. I guess my immediate problem is fixed finally, but I am really not confident the problem won't occur again the next outage on Tuesday. With the poor communication, I am only able to get about 2 days worth of week each week and it takes almost a week to successfully report it.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

It affects more than just Windows machines. I run OS/2 and Linux only. I think I fixed my problem by removing the AstroPulse 4.62 application reference in my app_info.xml file on my OS/2 machine.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)