| Author | Message |
|---|
|
|
|
I've been getting the message "Server can't open log file (../log_climateapps2/scheduler.log" each time a "trickle up" request is generated? Any problems?
David |
|
|
|
|
|
same here
____________
|
|
|
|
|
|
Yes, there were problems, as mentioned in this News post on our alternative board.
____________
Backups: Here |
|
|
|
|
|
Even though the server appears to be back OK on the server status page, communication is still failing with HTTP internal server error.
I presume this is known and still awaiting completion of the remedial work. |
|
|
|
|
|
Correct.
This board is back, plus a couple of other things, but not everything has been turned back on yet.
When you have a / and /root failure on a big Apache system, repairs and restores take time.
____________
Backups: Here |
|
|
|
|
|
. |
|
|
|
|
|
I'm succumbing to temptation - not expecting any comments- but why oh why don't organisations investing in huge hardware/database installations check back in history and use the only genuinely 365/24/7 system that has been proven across the world. Namely OpenVMS/Rdb. The last system I worked on had zero downtime in 10 years. (excluding 1 night out a year for new releases.) Yeah , I know - it's a legacy system. Oh well.
. |
|
|
|
|
|
well, my first log message for days "Scheduler request completed" without the dreaded "Scheduler request failed: HTTP internal server error" was at 15:55 BST and no sign of any recent trickle files in the data folder.
They don't seem to be showing on the database yet - I expect that's the huge backlog to process. At least there's some sign of life - well done for getting it up for the weekend!
I'll let another model run now as well as the long coupled models. /p |
|
|
|
|
|
Yeah, looks like the scheduler is accepting requests again. However, the last trickle showing on my 1 running model is from 09 Jul 2011 22:07:33. I know my computer has sent several trickles since then. I hope they're not lost. |
|
|
|
|
|
The server is also giving out new WU?s again. I just received a new CM3n after several of having an idle core. As everyone knows, an idle core is the devils workshop. :-)
____________
|
|
|
|
|
I'm succumbing to temptation - not expecting any comments- but why oh why don't organisations investing in huge hardware/database installations check back in history and use the only genuinely 365/24/7 system that has been proven across the world. Namely OpenVMS/Rdb. The last system I worked on had zero downtime in 10 years. (excluding 1 night out a year for new releases.) Yeah , I know - it's a legacy system. Oh well.
.
Well, it's the 1st. time I've heard of an OS that keeps running flawlessly then the hardware it's running on has stopped working...
|
|
|
|
|
|
Me too. I had only been going a couple of hours on a job when they shut down. Since then I have had several trickles fail and at least 3 since it came back on line and still none showing... Pain in the but If I've wasted 110 hours and more if this goes on.
Mike |
|
|
|
|
|
The trickles aren't showing because of the huge backlog of data on the upload servers that needs to be processed, at the same time as tens of thousands of computers want to download new work.
And it's been the weekend. Still is in some parts of the world.
And there's some more work to do on the servers. I think that some of the daemons haven't been started yet.
Patience is the best cure.
____________
Backups: Here |
|
|
|
|
|
Well, it's the 1st. time I've heard of an OS that keeps running flawlessly then the hardware it's
running on has stopped working...
Ah well, I did say 'installations' which naturally includes a backup server to facilitate 'fail over' procedures. Perhaps I should have added the detail, but OpenVMS has always been a world leader for its reliability,performance and continuity with a clustered environment, even across multiple sites. The clustering, together with various system services allow it to be virtually completely 'disaster tolerant'. An exception being if every site is nuked at the same time. |
|
|
|
|
|
Les
Thanks for that info. I was beginnibg to think I had lost it all. So I will be patient......
Mike |
|
|
|
|
"The trickles aren't showing because of the huge backlog of data on the upload servers that needs to be processed, at the same time as tens of thousands of computers want to download new work."
right now I can see trickles for Jul 10 & Jul 11 - so that's some activity, though not sure if any headway is being made into the backlog. how's things with others? /p
|
|
|
|
|
|
They all seem to be going through normally for me now.
Dave |
|
|
|
|
|
Re this message from Ananas: restarting the client doesn't help. I'm still getting "HTTP internal server error" on trickle-ups. |
|
|
|
|
|
server error is just that - one of the project's servers.
Usually a sign that the upload server is under heavy load from user's computers.
Restarting your 'client' in any form won't help. You just have to try again later.
The News message refers to errors such as 'server (or project), not found'.
____________
Backups: Here |
|
|
|
|
Re this message from Ananas: restarting the client doesn't help. I'm still getting "HTTP internal server error" on trickle-ups.
There are 2 errors that are not directly related.
As you already receive "real" server messages and not just "Scheduler request failed: Couldn't connect to server", your BOINC client already knows the correct IP. Those detailed errors are server side problems, restarting the client does not help.
But BOINC clients cache the IP forever (at least older ones do) and will continue giving you the "connect" error message even if the server is already up and running, just with a fresh IP.
I have 2 models running on 2 hosts, they both have been collecting trickles and were unable to upload them : "Couldn't connect ..."
I restarted only one and that one did upload the trickles, while the other one still sits there with the "connect" error. |
|
|
|
|
But BOINC clients cache the IP forever (at least older ones do) and will continue giving you the "connect" error message even if the server is already up and running, just with a fresh IP.
Don't remember the exact version, but this was fixed around v6.10.30, so any resent BOINC-clients shouldn't normally have any problems getting the new IP.
|
|
|
|
|
|
What I was suggesting (a bit subtly perhaps) is that perhaps the error is in fact HTTP 500, "Internal Error", and not HTTP 502, "Gateway Timeout" (= slow response from the database server), nor HTTP 503, "Service [temporarily] Unavailable", i.e. overload. Given that the machine has been rebuilt, and has changed to a new IP address, and all.
Edit: The point being that waiting would fix the latter two problems, but not the first. |
|
|
