Hmmm. OS/2 Warp, if I'm not mistaken. Looking at the SETI applications page, your operating system is not listed, so I guess there's no official, Berkeley-supported and Berkeley-hosted application for you.

So it must be a home-build or team-build version, right? And you must use the app_info.xml mechanism to get it to run?

That is, in fact, the primary purpose of the "anonymous platform" technique. And it's broken. If you use app_info, you get no work. And if you don't use app_info, you get no work. B****r.

All I can suggest is that you put pressure on David Anderson to get the BOINC Server source code fixed, perhaps adding to my bug report (trac ticket 194), or you put pressure on Eric and Matt to down-grade the BOINC servers to the earlier version of the BOINC server software. Neither will be easy, or welcome, but it's the best I can suggest. Sorry.

Edit - third possibility - could your team get the latest BOINC v5.9.11 to compile on OS/2? If so, there's a report in the Bugs...but where? thread - unconfirmed as yet - that the app_info will work again, and your existing application should work too.

Real edit - sorry, hit 'reply' to my own post instead of 'edit' - past midnight here, and I've been working on this one for 14 hours: time for bed very soon. But you get my drift....

Hmmm. OS/2 Warp, if I'm not mistaken. Looking at the SETI applications page, your operating system is not listed, so I guess there's no official, Berkeley-supported and Berkeley-hosted application for you.

So it must be a home-build or team-build version, right? And you must use the app_info.xml mechanism to get it to run?

That is, in fact, the primary purpose of the "anonymous platform" technique. And it's broken. If you use app_info, you get no work. And if you don't use app_info, you get no work. B****r.

All I can suggest is that you put pressure on David Anderson to get the BOINC Server source code fixed, perhaps adding to my bug report (trac ticket 194), or you put pressure on Eric and Matt to down-grade the BOINC servers to the earlier version of the BOINC server software. Neither will be easy, or welcome, but it's the best I can suggest. Sorry.

Edit - third possibility - could your team get the latest BOINC v5.9.11 to compile on OS/2? If so, there's a report in the Bugs...but where? thread - unconfirmed as yet - that the app_info will work again, and your existing application should work too.

Edit - third possibility - could your team get the latest BOINC v5.9.11 to compile on OS/2? If so, there's a report in the Bugs...but where? thread - unconfirmed as yet - that the app_info will work again, and your existing application should work too.

Richard,

If you're still awake, ;>)), do you know if v5.9.11 is stable enough for the rest of us to try as a possible fix?

Regards

Edit - third possibility - could your team get the latest BOINC v5.9.11 to compile on OS/2? If so, there's a report in the Bugs...but where? thread - unconfirmed as yet - that the app_info will work again, and your existing application should work too.

Richard,

If you're still awake, ;>)), do you know if v5.9.11 is stable enough for the rest of us to try as a possible fix?

Regards

5.9.11 won't fix it... ther server at S@H needs to be reverted back to a previous version. That will (most likely) fix the issues with clients using optimized or unsupported platforms.

Anything else won't do.

---

Join BOINC United now!

Edit - third possibility - could your team get the latest BOINC v5.9.11 to compile on OS/2? If so, there's a report in the Bugs...but where? thread - unconfirmed as yet - that the app_info will work again, and your existing application should work too.

Richard,

If you're still awake, ;>)), do you know if v5.9.11 is stable enough for the rest of us to try as a possible fix?

Regards

5.9.11 won't fix it... ther server at S@H needs to be reverted back to a previous version. That will (most likely) fix the issues with clients using optimized or unsupported platforms.

Anything else won't do.

Bummer, but thanks.
[EDIT] You're still awake too! [/EDIT]

Edit - third possibility - could your team get the latest BOINC v5.9.11 to compile on OS/2? If so, there's a report in the Bugs...but where? thread - unconfirmed as yet - that the app_info will work again, and your existing application should work too.

Richard,

If you're still awake, ;>)), do you know if v5.9.11 is stable enough for the rest of us to try as a possible fix?

Regards

Still awake, just!

The original poster in Bugs has withdrawn - apparently, v5.9.11 doesn't fetch new work without the 'ghosts' trick.

So, as Crunch3r says - or v5.9.12, anyone?

Edit - third possibility - could your team get the latest BOINC v5.9.11 to compile on OS/2? If so, there's a report in the Bugs...but where? thread - unconfirmed as yet - that the app_info will work again, and your existing application should work too.

Richard,

If you're still awake, ;>)), do you know if v5.9.11 is stable enough for the rest of us to try as a possible fix?

Regards

Still awake, just!

The original poster in Bugs has withdrawn - apparently, v5.9.11 doesn't fetch new work without the 'ghosts' trick.

So, as Crunch3r says - or v5.9.12, anyone?

Well, the good news is that the workaround does the trick even if it is a little labor intensive.

Edit - third possibility - could your team get the latest BOINC v5.9.11 to compile on OS/2? If so, there's a report in the Bugs...but where? thread - unconfirmed as yet - that the app_info will work again, and your existing application should work too.

Richard,

If you're still awake, ;>)), do you know if v5.9.11 is stable enough for the rest of us to try as a possible fix?

Regards

Still awake, just!

The original poster in Bugs has withdrawn - apparently, v5.9.11 doesn't fetch new work without the 'ghosts' trick.

So, as Crunch3r says - or v5.9.12, anyone?

5.9.12 won't do either until the seti servers are reverted back to a server version that works (the one before the whole crash)....

@Gus
Yeah i'm still awake :D

---

Join BOINC United now!

We've been getting together in our IRC channel, with half dozen long term Seti guys running optimized apps. We've been playing with renaming the app_info file, restarting Manager, etc., and verify it will clear up our problems as has been reported.

But, the weird thing is, we are still running Chicken's optimized client, without an app_info being loaded (verified at start of Manager, in messages), and shows in Task Manager as Chicken's app is the client being run.

Our understanding is that the app_info file tells manager to run anonymous platform clients? So what gives? Not that we're complaining, Seti is working, and we're running optimized clients....

---

Team Starfire World BOINC
IRC- irc//irc.teamstarfire.net:6667/team_starfire

...
But, the weird thing is, we are still running Chicken's optimized client, without an app_info being loaded (verified at start of Manager, in messages), and shows in Task Manager as Chicken's app is the client being run.

Our understanding is that the app_info file tells manager to run anonymous platform clients? So what gives? Not that we're complaining, Seti is working, and we're running optimized clients....

I asume while having a very very short look at the new boinc client code is that it has something to to with the "signed code"....

I'm not an expert on this one but i "guess" that what you and your team mates have seen is either an affect of running a new boinc client or (that's what's more likely) the new server code at S@H with signed apps turned off...

However ... i might be totaly wrong on this one ... please correct me if i'm wrong.

---

Join BOINC United now!

...
But, the weird thing is, we are still running Chicken's optimized client, without an app_info being loaded (verified at start of Manager, in messages), and shows in Task Manager as Chicken's app is the client being run.

Our understanding is that the app_info file tells manager to run anonymous platform clients? So what gives? Not that we're complaining, Seti is working, and we're running optimized clients....

I asume while having a very very short look at the new boinc client code is that it has something to to with the "signed code"....

I'm not an expert on this one but i "guess" that what you and your team mates have seen is either an affect of running a new boinc client or (that's what's more likely) the new server code at S@H with signed apps turned off...

However ... i might be totaly wrong on this one ... please correct me if i'm wrong.

I noticed the same thing, even after renaming app_info and restarting BOINC, if the WU started with the chicken it continues running the chicken. New WU's use the stock app.
I had assumed the optimized app name was stored in client_state or in the result file, but I could not find it there. I did notice that KWSN_2.2B_SSE2-P4_Ben-Joe.exe is still in the slot folder so I now assume that it just keeps using it from there until done.
. . . BUT that's just a guesstimate.

Edit - just had another thought. When you upgrade to chicken soup, the stock app is automagically deleted thus forcing BOINC to use chicken. When you downgrade back to the stock app chicken is NOT deleted. That might explain why this behaviour is unilateral.
Also, when I said I could not find the app in client_state that is not quite right. It's there but does not seem to be linked to the results that are in progress, I think.

All of these deleting files ideas are great. Restarting Boinc, good advice. I've done it about 6 or 7 times today.

The problem is that if you can't reach the project none of these fixes work.

I get a lot of "Scheduler request failed: server returned nothing (no headers, no data)"

And some "Scheduler request failed: HTTP internal server error"

But neither is consistent. Sometime I can upload and sometimes I can report. I cannot get new work no matter what I do.

Now I get "Scheduler request failed: failed sending data to the peer"

So, If I can't reach the project 9 out of 10 attempts, and I cannot get work on that 1 attempt, what am I going to do. I suppose that when I do (not if) run out of work, I can detach or uninstall Boinc and start over. However, with each detach or uninstall, the probability of me returning to this project keeps reducing.

I know everyone is working hard, but...it shouldn't be this difficult for us to participate. People will leave and some may never return.

"Scheduler request failed: server returned nothing (no headers, no data)" - congestion
"Scheduler request failed: failed sending data to the peer" - congestion
"Scheduler request failed: HTTP internal server error" - you are running an optimised app, and the scheduler is broken.

[probably - your computers are hidden, which makes helpful troubleshooting next to impossible. But your signature banner tends to imply an optimiser]

Look at Number Crunching, and the 'Ghosts' thread - your solution is there.

Yes, I am running optimized apps. Some of my boxes have now D/L'd the stock app after renaming app_info. Others have not been so fortunate.

I guess I forgot to mention receiving "No Work from Project" messages...very frustrating to finally connect and get that message. Other boxes will simply not request work. Caches are running low and they may run out of work this weekend, and I won't have access to them until Monday. Detaching does work, but I will not do that until a system is dry, besides, it's too much work. My systems are spread out and I have better things to do with my time than run around and babysit them all.

I appreciate the efforts of all, your suggestions are helping...I just wish they were consistently effective. That's not the fault of yours, the project is unstable <sigh> guess I'll go back to Grin and Bear it mode.

---

..

"Scheduler request failed: HTTP internal server error" - you are running an optimised app, and the scheduler is broken.

I’ve also been getting that message from Beta, where I’m not running an optimized app.

---

5.9.11 won't fix it... ther server at S@H needs to be reverted back to a previous version. That will (most likely) fix the issues with clients using optimized or unsupported platforms.

Anything else won't do.

Not even fixing it so it recognises the modified clients?
Odd attitude.

---

Grant
Darwin NT

"Scheduler request failed: HTTP internal server error" - you are running an optimised app, and the scheduler is broken.

I’ve also been getting that message from Beta, where I’m not running an optimized app.

Yep. Same problem for me with the Beta project. Can't even upload completed results.

---

Dublin, California
Team: SETI.USA

"Scheduler request failed: HTTP internal server error" - you are running an optimised app, and the scheduler is broken.

I’ve also been getting that message from Beta, where I’m not running an optimized app.

When I first reverted back to stock using the work around, I too intermittently received the "http error" message. However; I kept a close eye on my Results Page, hitting Reload on the Browser every time the error came up. With Stock running, the error message will NOT produce "Ghosts"... For whatever reason; ONLY the Optimized App and receiving the "http error" message produces "Ghosts".

Simply put; while back on Stock and running, don't worry about it for now. It is something that needs to be looked into by Eric, Matt, and crew. While on Stock, the error seems to be harmless.


Sincerely,

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

Hi folks,

to clear up a common misconception: the optimized apps have nothing at all to do with the current problem. All transfers are handled by BOINC itself, the science apps only crunch what BOINC fetches for them.

The current problem lies within the (anonymous) platform mechanism and app_info.xml, the associated settings file. Somehow, the scheduler is erroring out when such a file is present, no matter what application you have in there. Try making an app_info.xml containing the stock app and see for yourself ;o)

Also, I've noticed something else that maybe points to a probable cause for our trouble - as at least one other person noticed, I can no longer grab work at all with my 64-bit BOINC client, no matter whether I delete/rename app_info.xml or not.

The specific error message looks like this -

2007-05-18 15:03:44 [SETI@home] Sending scheduler request: To report completed tasks
2007-05-18 15:03:44 [SETI@home] Requesting 259200 seconds of new work, and reporting 18 completed tasks
2007-05-18 15:04:19 [SETI@home] Scheduler RPC succeeded [server version 509]
2007-05-18 15:04:19 [SETI@home] Message from server: platform 'x86_64-pc-linux-gnu' not found
2007-05-18 15:04:19 [SETI@home] Deferring communication for 1 days 0 hr 0 min 0 sec
2007-05-18 15:04:19 [SETI@home] Reason: requested by project

which repeats as often as it tries to grab new work and actually gets through to the scheduler. It can't even report its work.

So - it really seems like it's a problem with ANY non-standard platform, be it "anonymous" or, like here, "x86_64-pc-linux-gnu". I also tried the official 64-bit BOINC build, but it wants a newer GLIBC than my Gentoo system has to offer, so no go there (it may have a different platform string, haven't checked).

Basically, it looks like the recent server code edit has a problem with platforms as a whole, not just with "anonymous" ones.

Reverting to 32-bit BOINC (platform string: i686-pc-linux-gnu) got me new work (without app_info.xml, anyway).

HTH,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Yep ... just to confirm
I'm getting the same as everyone else
SETI@home Beta Test | Scheduler request failed: HTTP internal server error

I run only one project ... SETI@home / AstroPulse / Beta testing
and no Chicken Soup ... Optimized app.
Boinc 5.8.16
WXPSP2

5/19/2007 6:17:55 AM|SETI@home Beta Test|Sending scheduler request: Requested by user
5/19/2007 6:17:55 AM|SETI@home Beta Test|Requesting 21600 seconds of new work, and reporting 1 completed tasks
5/19/2007 6:18:00 AM|SETI@home Beta Test|Scheduler request failed: HTTP internal server error
5/19/2007 6:18:00 AM|SETI@home Beta Test|Deferring communication for 14 min 16 sec
5/19/2007 6:18:00 AM|SETI@home Beta Test|Reason: scheduler request failed

Thanks for the clarification, Chicken.

So now I have to ask the question...Can we "trick" the system from our end? Not just by removing the app_info file, but somehow modify the platfrom information. I have team mates that are having the same issue with 64bit Linux

---

..

Well since It's a server problem, Will Seti go back to the Previous software or Are they going to stick anyone who uses any non stock app in the "No Work Zone"? Cause until It's fixed one way or the other, It's like only the Stock app is supported by Seti and It may as well be closed source, Cause Seti is sure acting like It unless One tricks Seti with a work around just to get downloads Which is Tedious on more than 1 PC and I've got 5 PCs now. So Somebody fix this, Please? :(

---

Savoir-Faire is everywhere!
The T1 Trust, T1 Class 4-4-4-4 #5550, America's First HST