Just after I posted yesterday's tech news message we had to reboot kryten and penguin as they both lost NFS mounts. In fact, we had to boot kryten twice (as it came up immediately being unable to mount bruno's disks). I really wish I knew what was causing these to happen, but perhaps this problem will simply just "time out."

The first technical issue for today was the hill shuttle bus broke down, so I got in a few minutes later than expected. This at least afforded me an extra few minutes to complete a rather pesky sudoku puzzle. Take that, unruly numbers!

So what happened with the replica yesterday? Turns out, for some (currently) inexplicable reason the .MYD files under data/mysql were all zero length. None of the other files were affected, just the .MYD's. Oddly their time stamps were sane (they were rather old as they haven't been updated in a while). So what emptied out these very specific files but didn't update their time stamps? In any case, we're forced to recover the replica from scratch (not that big a deal). Bob was finally able to wiggle his way in to at least clean out the current database so we can drop everything and reload. We might have an outage soon to dump the current data for such a reload.

Meanwhile, bruno progresses. Making it the new upload server was held up on being able to compile a working fastcgi-enabled file_upload_handler. Jeff finally got one to compile. So we embarked on what should have been a quick transition - basically just moving a cable from one jack to another and updating DNS. However the file_upload_handler didn't work. Refusing to debug it I suggested we just use a normal garden variety handler without the fastcgi hooks. All the fastcgi was buying us was process spawning overhead. This was a major necessity on our old n' slow 3500, but bruno didn't even break a sweat once we fired it up. So bruno is now our upload server!

But wait! After a half hour or so I noticed the traffic graphs were a bit "dampened." Why weren't we sending out as much data as before? After finding no obvious bottlenecks we dug out a gigabit switch and split the Hurricane link so both kryten and bruno could act as simultaneous upload servers. Sure enough, a third of our clients were still trying to connect to the kryten address. This is odd as the DNS entry has a 5 minute TTL (time to live). Perhaps we're seeing the effect of DNS caching (in Windows or otherwise). Fair enough - we'll leave both kryten and bruno up as "mirror" servers as DNS (hopefully) corrects itself over the coming days. I'll reflect the changes in the server status page eventually.

- Matt

... we had to reboot kryten and penguin as they both lost NFS mounts. ... but perhaps this problem will simply just "time out."

As I suspected, Matt is another Sudoku fan. Is the rest of the group there into it, also?

I love the professional puzzles. *Most* of the time I finish them in 20-25 minutes, but there are a few that take a little longer. I now need to get into the Hex ones, or the 26 letter ones and see what I can do with those puppies.

Matt,

I don't know if anyone has made you or any member of your team aware of this, or if anything can be done about it, but yesterday and the day before there were a fairly considerable number of results marked as invalid. I'll guess that it was due to Kryten losing it's mounts or a glitch during the switchover to Bruno, but whatever the cause I wanted to be sure you knew about it in case adjustments can be made.

Many of these have been posted in Number Crunching in the "Validate Errors - Please post them" thread. Of course I know that you and your team don't have time to read all of the boards so I'm bringing this to your attention here in the hopes that it will be noticed.

One issue is that the earliest of these have already been resent and reported, and so are in danger of being deleted. So, in the event that credit may be granted I guess time is becoming a factor.

Whatever, thanks for your hard work and that of the rest of the Berkeley crew in the effort to keep this project going despite all of the limitations; hardware, manpower and otherwise.

Regards,

Gus Obermeyer (gomeyer)

> @ Gus - see Matt's NEW POST - Ups and Downs (Mar 22 2007)

edit - sorry 'bout Link (fixed)

Very good news indeed! Thanks for all your efforts. Let's hope that Bruno lives up to the expectation we all have for it. Congrats to all the people involved in the switch.

Regards,
Wander

"I'm trying to maintain a shred of dignity in this world." - Me

Perhaps my problem has something to do with this, perhaps not. At any rate, my Seti completed task does not upload because it is "locked by file upload handler". I had this problem with the previous task and eventually I just detached and reattached, meaning I had lost all credit.
I have also had problems with Climateprediction, i.e. unable to contact server. Are the problems related. Is there a solution for a poor computer semi-illiterate?

Perhaps my problem has something to do with this, perhaps not. At any rate, my Seti completed task does not upload because it is "locked by file upload handler". I had this problem with the previous task and eventually I just detached and reattached, meaning I had lost all credit.
I have also had problems with Climateprediction, i.e. unable to contact server. Are the problems related. Is there a solution for a poor computer semi-illiterate?

What is the retirement plan for the old suns? (No I don't mean 401k's)

What is the retirement plan for the old suns? (No I don't mean 401k's)

Hmmm... and I was going to say black holes or white dwarfs.

What is the retirement plan for the old suns? (No I don't mean 401k's)

Hmmm... and I was going to say black holes or white dwarfs.