Ashoat

It looks like this issue resolved itself?

Now that Stevie's looking better we can try to get people to sign up there instead of with Johnny so we don't have so many accounts on Johnny. I'll also configure Stevie is host one of our two nameservers so HelioHost DNS is more reliable.

Haha yeah, I just re-enabled the firewall. Looks like the NIC couldn't handle all the traffic that somebody was spamming... we also went from like 80mbps use to like 3mbps use. Really glad we got this solved!

Please check with me before you make any of those sort of changes in the future.

APC is installed?

Okay, I went in and manually corrected everything. You should be able to switch your nameservers now. Let me know if you aren't able to.

Stop making intentional misspellings. Read the big, red text and spell correctly. I can't tell what you're saying. Your crontab must be configured to only run two cronjobs in a day.

If you're running more than 2 cronjobs every day then all your all crons will be deleted. Are you running more than 2 cronjobs per day?

I'd be wary of removing pcre-6.6.6 as RHEL hasn't updated yet. Is it possible to install pcre-7.7 to a separate location and to compile APC with a custom PCRE path?

This is feeling like a hardware issue. Definitely not on Apache's end or anything. Compare the ping patterns: Stevie: ashoat$ ping 65.19.143.2 PING 65.19.143.2 (65.19.143.2): 56 data bytes 64 bytes from 65.19.143.2: icmp_seq=0 ttl=54 time=8.674 ms 64 bytes from 65.19.143.2: icmp_seq=1 ttl=54 time=4.040 ms 64 bytes from 65.19.143.2: icmp_seq=2 ttl=54 time=6.876 ms 64 bytes from 65.19.143.2: icmp_seq=3 ttl=54 time=6.753 ms 64 bytes from 65.19.143.2: icmp_seq=4 ttl=54 time=5.171 ms 64 bytes from 65.19.143.2: icmp_seq=5 ttl=54 time=6.472 ms 64 bytes from 65.19.143.2: icmp_seq=6 ttl=54 time=6.444 ms 64 bytes from 65.19.143.2: icmp_seq=7 ttl=54 time=3.401 ms 64 bytes from 65.19.143.2: icmp_seq=8 ttl=54 time=4.694 ms 64 bytes from 65.19.143.2: icmp_seq=9 ttl=54 time=8.337 ms Request timeout for icmp_seq 10 64 bytes from 65.19.143.2: icmp_seq=11 ttl=54 time=42.790 ms Request timeout for icmp_seq 12 Request timeout for icmp_seq 13 Request timeout for icmp_seq 14 Request timeout for icmp_seq 15 Request timeout for icmp_seq 16 Request timeout for icmp_seq 17 Request timeout for icmp_seq 18 Request timeout for icmp_seq 19 64 bytes from 65.19.143.2: icmp_seq=20 ttl=54 time=51.253 ms Request timeout for icmp_seq 21 Request timeout for icmp_seq 22 Request timeout for icmp_seq 23 Request timeout for icmp_seq 24 Request timeout for icmp_seq 25 Request timeout for icmp_seq 26 64 bytes from 65.19.143.2: icmp_seq=27 ttl=54 time=46.454 ms 64 bytes from 65.19.143.2: icmp_seq=28 ttl=54 time=42.953 ms Request timeout for icmp_seq 29 64 bytes from 65.19.143.2: icmp_seq=30 ttl=54 time=45.583 ms 64 bytes from 65.19.143.2: icmp_seq=31 ttl=54 time=41.809 ms Request timeout for icmp_seq 32 64 bytes from 65.19.143.2: icmp_seq=33 ttl=54 time=44.662 ms 64 bytes from 65.19.143.2: icmp_seq=34 ttl=54 time=43.495 ms Request timeout for icmp_seq 35 Request timeout for icmp_seq 36 64 bytes from 65.19.143.2: icmp_seq=37 ttl=54 time=42.187 ms Request timeout for icmp_seq 38 64 bytes from 65.19.143.2: icmp_seq=39 ttl=54 time=46.252 ms Request timeout for icmp_seq 40 Request timeout for icmp_seq 41 Request timeout for icmp_seq 42 64 bytes from 65.19.143.2: icmp_seq=43 ttl=54 time=42.497 ms Request timeout for icmp_seq 44 Request timeout for icmp_seq 45 Request timeout for icmp_seq 46 64 bytes from 65.19.143.2: icmp_seq=47 ttl=54 time=42.923 ms Request timeout for icmp_seq 48 64 bytes from 65.19.143.2: icmp_seq=49 ttl=54 time=44.294 ms Request timeout for icmp_seq 50 64 bytes from 65.19.143.2: icmp_seq=51 ttl=54 time=44.736 ms 64 bytes from 65.19.143.2: icmp_seq=52 ttl=54 time=46.710 ms Request timeout for icmp_seq 53 Request timeout for icmp_seq 54 64 bytes from 65.19.143.2: icmp_seq=55 ttl=54 time=43.471 ms Request timeout for icmp_seq 56 64 bytes from 65.19.143.2: icmp_seq=57 ttl=54 time=44.710 ms Request timeout for icmp_seq 58 64 bytes from 65.19.143.2: icmp_seq=59 ttl=54 time=46.111 ms 64 bytes from 65.19.143.2: icmp_seq=60 ttl=54 time=47.208 ms Request timeout for icmp_seq 61 64 bytes from 65.19.143.2: icmp_seq=62 ttl=54 time=43.252 ms Request timeout for icmp_seq 63 ^C --- 65.19.143.2 ping statistics --- 65 packets transmitted, 30 packets received, 53.8% packet loss round-trip min/avg/max/stddev = 3.401/31.807/51.253/18.300 ms Charlie: ping 64.62.211.131 PING 64.62.211.131 (64.62.211.131): 56 data bytes 64 bytes from 64.62.211.131: icmp_seq=0 ttl=54 time=6.261 ms 64 bytes from 64.62.211.131: icmp_seq=1 ttl=54 time=7.245 ms 64 bytes from 64.62.211.131: icmp_seq=2 ttl=54 time=17.679 ms 64 bytes from 64.62.211.131: icmp_seq=3 ttl=54 time=6.886 ms 64 bytes from 64.62.211.131: icmp_seq=4 ttl=54 time=3.846 ms 64 bytes from 64.62.211.131: icmp_seq=5 ttl=54 time=5.068 ms 64 bytes from 64.62.211.131: icmp_seq=6 ttl=54 time=6.939 ms 64 bytes from 64.62.211.131: icmp_seq=7 ttl=54 time=7.360 ms 64 bytes from 64.62.211.131: icmp_seq=8 ttl=54 time=5.875 ms 64 bytes from 64.62.211.131: icmp_seq=9 ttl=54 time=6.680 ms 64 bytes from 64.62.211.131: icmp_seq=10 ttl=54 time=4.582 ms 64 bytes from 64.62.211.131: icmp_seq=11 ttl=54 time=13.068 ms 64 bytes from 64.62.211.131: icmp_seq=12 ttl=54 time=3.598 ms 64 bytes from 64.62.211.131: icmp_seq=13 ttl=54 time=6.716 ms 64 bytes from 64.62.211.131: icmp_seq=14 ttl=54 time=23.143 ms 64 bytes from 64.62.211.131: icmp_seq=15 ttl=54 time=31.943 ms 64 bytes from 64.62.211.131: icmp_seq=16 ttl=54 time=25.994 ms 64 bytes from 64.62.211.131: icmp_seq=17 ttl=54 time=56.681 ms 64 bytes from 64.62.211.131: icmp_seq=18 ttl=54 time=5.782 ms 64 bytes from 64.62.211.131: icmp_seq=19 ttl=54 time=6.376 ms 64 bytes from 64.62.211.131: icmp_seq=20 ttl=54 time=17.729 ms 64 bytes from 64.62.211.131: icmp_seq=21 ttl=54 time=4.384 ms 64 bytes from 64.62.211.131: icmp_seq=22 ttl=54 time=7.209 ms 64 bytes from 64.62.211.131: icmp_seq=23 ttl=54 time=34.841 ms 64 bytes from 64.62.211.131: icmp_seq=24 ttl=54 time=7.089 ms 64 bytes from 64.62.211.131: icmp_seq=25 ttl=54 time=5.170 ms ^C --- 64.62.211.131 ping statistics --- 26 packets transmitted, 26 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.598/12.621/56.681/12.367 ms It also doesn't seem to be the upstream router - pings there return fine. I'm guessing it might be the network card, and I'm hoping it's the patch cable. I'll be gone for most of this weekend but I'll see if I can replace the patch cable sometime early next week.

What's the error? Have you tried doing it from source?

gdzie111, is that your account? Also, please set the nameservers correctly as Geoff specified.

Something I've noticed recently: Roundcube is taking a whole lot of CPU time. I'll disable it and see if that helps.

Geoff: what did you change? And we are running Mongrel servers for Ruby on Rails. Are those working? They are piped through Apache's mod_proxy, but you can access them directly on the localhost by accessing the port the server is broadcasting on.

Okay, I think I've deleted all records. Can you try again now?

Nice catch, Geoff! Glad to have you back to figure these things out. Have you previously encountered this issue, or did you just Google it?

jje: Minor correction, at this point, HelioHost is self-sustaining

Okay, perhaps you're right. Would you be up for setting it up?

Krydos: More like 48 hours, if you're including folks on other continents and/or using slower connections. Panos80: You're not paying attention to the scripts you're running. "Please wait 48 hours for the change to take effect." is not a joke; it's serious. Your site isn't going to be up in 3 hours. If you have a problem, then leave. This is a free hosting site; you're a user, not a customer.

The usage case still seems dubious... How exactly does it cache data? Are there specific PHP functions it uses? Where does it store that information? /tmp?

Possibly... is there a way to diagnose something like that?

"Linux" being corrupted doesn't make sense (what would that entail?), and if the CPU/motherboard was damaged then Stevie would more likely just not be working at all...

Looks like what's going on here is that a domain change broke halfway through. The entry for femaleonly.co.cc is corrupted, and though its DNS currently seems to be propagating, cPanel's entry is corrupted such that it will never generate a VirtualHost entry in httpd.conf for it. On the other hand, femaleforum.eu seems to be configured correctly on our end, but doesn't seem to be pointed to HelioHost. Set the nameservers on that domain to ns1.heliohost.org and ns2.heliohost.org and once it propagates the domain should show up. I've updated our database to list your new main domain (femaleforum.eu) correctly and I've deleted the corrupt entry for femaleonly.co.cc. Try adding femaleonly.co.cc again, and make sure you set your nameservers correctly.

No, I tried an e2fsck --force earlier.