It's not. You shouldn't even be able to connect, since I killed all the public-facing servers until wizkid057 can fix them.

Looks like a drive failure on the main database machine... working on it.

Trying to get us back up, at least in failsafe mode, for now.

my miners switched all to an other pool. I can able to connect to eligius pool.

What happen?

 :)Thx

OK, so, rebuilt missing shares from the backup logging method, pool is coming back online.  Spent an extra hour offline to make sure there is no extended failsafe.

Bear with it as it is working on re-accepting over 100,000 connections...

I'm going to work on revising the main database server later so that this can't happen again.

Concerning backup pools:

I have 8 S1s:
First 4: Eligius (pool 1); BTC (pool 2); Slush (pool 3)
Second 4: Slush (pool 1); Eligius (pool 2); BTC (pool 3)

Don't like using Slush for backup because you really get dinged because of pool-hopping perception.

Results for Eligius and Slush when both are working well about even. Sometimes one will have much better luck than the other but I noticed in the long run they put out about the same (even with the Slush fee).

But tried running BTC Guild as primary for 3 weeks and it just didn't seem to pay as much as Eligius and Slush. Possible BTC just had a bad 3 weeks but I was wondering if anybody else was seeing the same at BTC?

Something I've done in the past to make a system usable while the main RAID array is being rebuilt (Linux md-raid though, this doesn't help if you're using hardware raid) was to reshape the max and minimum rebuild speeds:

echo 20000 >proc/sys/dev/raid/speed_limit_min
echo 100000 >proc/sys/dev/raid/speed_limit_max

Which would set the minimum rebuild speed to 20MB/s and the maximum to 100 MB/s, which may give you some breathing room (you can permanently set this inetc/sysctl.conf on most distros).

Bear in mind, that the one time I actually made heavy use of this (3 days while hitting the array really hard) I had a -second- drive die in my RAID-5 array, and I am still trying to perform post-mortem array recovery on it now. So don't use a slow rebuild as a reason not to return to a parity state, but it can help out in a crisis.

Yes I noticed that as well.  I didn't run it for 3 weeks, but I noticed the daily payouts were less on BTC Guild.  Eligius gives better payouts from my experience.  And I like the no registration system.  Unfortunately I had to use BTC Guild this morning when I awoke to Eligius being down.  I hope the hardware problems are corrected 100% soon.    

Front-end crashes and fail-safe modes don't bother me too much, since I know nothing is lost, only delayed, but back end crashes like last night are concerning.  That's costing me money.  Well, it was my fault to not have a secondary pool specified, so that's my fault.

There is no port 12234.
Sounds like you need to upgrade your miner.

I think what happened was that the hot spare kicked in, but the rebuilding overtaxed the drive and kicked the database offline.

Too late now, but any new hot spares should be configured to be throttled a bit so it doesn't happen again.   

12234 is basically a beta port at this point.  Don't expect it to be 100% up.

Hardware issues are resolved, pool is working normally.

Working on getting hardware upgrades in place also, but, shouldn't be any noticeable downtime.

Edit: As for low starting diff, probably going to bump Eligius's minimum difficulty another notch soon.  A difficulty 16 share is not even worth 4 satoshi at 100% PPS now.  So, useless anyway IMO.  Probably going to bump to minimum diff 64.  Less than 15% of the pool will notice any difference in their vardiff from this anyway, but will have a more reasonable starting diff for most miners.