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.

Geoff: what do you change?

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.