I had that problem too, in my case the reason was that I had used the old account file with just the new URL inserted.

Account filename and entry have to match it seems.

It created a second account file on each contact but it didn't trash or rename the file with the wrong name, so I ended up with 2 Pirates projects in client_state.xml of which one never had a chance to receive a new HostID.

As both projects had the same name, it always asked for a new ID here but it wouldhave needed one for the old server to be satisfied.


BOINC should catch that but otoh. they sure will say "leave those XMLs alone and use the menu"


p.s.: probably not the same reason this time, it behaves different, no second Pirates entry and no URL / filename mismatch

Just wanted to add that I'm using a development client version (CPDNBBC 5.3.9) and (re-) attached to Pirates via an Account Management System which is currently beta tested. I don't have multiple host entries with 'normal' attaching via BOINC manager (just checked this out...) but as other people had the same problem I'm not sure where the bug is... ;)

Could it be that the AMS is fighting with the BOINC manager or client about the URL?

At some point I may switch the Vassar link back to the archive for mission 1 (as it should be) and we'll see what that does for this. And how many new problems it creates. :-)

Willy - thanks for all the information. I certainly meant no disrespect to your code when suggesting something to check for.

This cloning of hosts isn't a Pirates problem alone, a team mate who crunches Rosetta just told me, that he has the same problem. It must be the new server side software version.

5.2.15 failed in alpha testing. Don't really know the reason, AFAIK 5.2.13 is the "recommended" release:

Email from David A follows:

David Anderson to boinc_alpha
More options Jan 17 (7 days ago)

Testing of 5.2.15 is complete (I think - is it, Rom?)
It didn't pass.

No problems here!!
____________
Join us in Chat (see the forum) Click the Sig


Join UBT

To me it happened with 4.19

It could also be a strange interaction between the project server and the account manager, right?

I can imagine where it comes from :

The first scheduler (pirates.spy-hill.net/cgi-bin/scheduler) contact nearly always fails although there seems to be a scheduler listening.

It goes to the second scheduler (pirates.spy-hill.net/cgi-bin/cgi) immediately and receives a new ID, not knowing that the first scheduler created a new ID for the same machine too.

Sometimes both scheduler contacts fail, both create an ID but the reply never arrives and the BOINC client will continue asking for an ID.

I get failed scheduler contacts very often here, some assigning work that never arrives, some for receiving an ID that never arrives.

Is there a way to increase the debug output of CC 4.19 so I can check what happens? No paket monitor available so that is not an option ;-)


edit : could it be a DSL problem with the Max. MTU size ?

*sigh* I give up, I tried several MTU sizes from 1500 down to 1000 but no change so this is probably not the reason.

It gives me a sched_reply with a fresh Host-ID on each contact but CC 4.19 still insists "no scheduler responding".

I didn't have that on any other project server, including vassar.

This is the condition for this error - just in case you didn't keep the ancient source ;-) :

http_op.http_op_state == HTTP_STATE_DONE (not so bad)
http_op.http_op_retval != 0 (this must be the failure detection)
log_flags.sched_ops = true (well, that's only for printing out the message)

I didn't find a flag to force logging of http_op_retval, later clients seem to have it :-/

I'm not using a proxy btw., connection through a Barricade router with builtin ADSL modem

p.s.: Cori, who started this thread, is probably using the same ISP, it's the most used one here in germany.

p.p.s.: I already had this box attached, through exactly the same network config, but decided to detach it when I found zillions of ghost WUs in my result list.

*sigh* much work and 4.19 isn't as bloated as later versions - plus I prefer to have control over the scheduling, the new scheduler encroaches into things I prefer to keep in my hands.

I'm not sure if it would be a good idea anyway, they changed the firewall/proxy handling to cURL lately and some of my boxes are behind a Squid with auth - others have trouble with this and I didn't bring other DC programs using cURL through this Squid either so far (wget works though, it uses cURL)

A team mate already gave up trying to bring 5.3.x through a Squid/auth.

I don't think it's a version problem, no trouble with other projects using 502 or 503 on server side.


It's not really a problem for me if I cannot attach - I run without graphics so I'm not too helpful for screensaver developement anyway.

There has been one interesting effect with FaD (which uses cURL) on Linux.

Using the program's proxy setup, the protocols (FaD dumps the HTTP headers) looked as if it didn't even try to authenticate - it did access the proxy though.

Using no proxy setup I got the expected errors.

Using the same environment variables that wget knows did try proxy but did not try to authenticate either. The interesting part here is, that the program hasn't been thought to use environment variables - so it might be necessary to tell cURL not to check the environment in order to make the program settings work or make it check only the environment and ignore the program settings.


It's very likely that the BOINC problems with Squid/Auth are close related.