HostGator NOT for resellers

[bqikbill]

If you haven't transferred your existing accounts to HG yet, here's a word for you: DON'T!

HG may be fine for a personal site, but not for businesses or resellers. Their speed is fine, but their tech support staff is basically non-existant. Naturally, level 1 tech support is the typical "entry level" that eveyone has to fight their way thru, but the *real* server admins are not much better. Here's my latest issue:

POP email went down on my shared server Saturday. Don't know exactly when, but when *my* phone started ringing around noon, I notified HG. This was the 3rd or 4th email issue we've had within the last 6 or 8 months. They got it fixed in about an hour or so, but when I asked what caused it, I got nowhere.

Sunday morning I got up to an email issue again! I had phone messages starting at 6 AM from my clients, so I know it happened before then. I notified HG when I got up around 9 and they were unaware of it, (so much for "monitoring", even when there's been a previous issue), and it took a couple hours to get it fixed again.

When I got done what I had to attend to on Sunday AM, I started trying to find out what caused these two outages which they described as a clogging up of the email queue. Was it one of my customers causing it ... was there any action I could take to help prevent it, etc. After all, almost all of my clients are businesses, some of which rely SOLELY on email for their livlihood, and a couple of them were a bit upset.

I had to ask several times, and pasted in below is the final request, followed by HG's unbelievable answer:

Me:
"I'm still concerned that whatever has caused the "clog" will happen again, since that is just the symptom of a problem, not the problem itself! It's happened twice in the last two days, all of my clients are businesses, and many of them rely on their email for their livlihood! Did they take ANY steps towards identifying the cause so they could rectify it?"

HG's unbelievable response when they could no longer side-step the question:
"I apologize but it does not seem that any steps were taken towards determining the cause of the issue.
At this time, we will just need to wait for it to happen again in order to assist with tracking down the issue."
Jerry Smith, System Admin I, Hostgator.com Ticket ID BFA-12360650

I won't bother quoting Lewis Black's immortal line of incredulity here, but we all know what it is.

So, naturally, happen again it did. Service went down again at 10:30 Sunday night, and wasn't noticed/fixed until 2:30 in the morning. I now have two clients whose business I worked very hard to get threatening to leave thanks to incompetent system administration at HG. And I still don't know what happened, how it happened, is one of my clients causing it, it there something I can do to assist in making sure it doesn't happen again ... nothing.

It's a shame, but the only way you can bring any real attention to a problem at HG is by wasting your time with a negative post in this forum. Note that almost all the positives here started out as negatives, a real problem that the customer couldn't get resolved thru normal phone or chat support channels.

Trust me, if it wasn't for the fact I'm still suffering from PTSD over the nightmare of transferring my domains to HG in the first place, I'd be out of here. Due to the way I do business, I have a 97% retention rate for hosting, and HG is on the verge of COSTING me customers. The bitter irony of it all is that I initially transferred to HG to get away from the chronic email issues with my previous service.

[GatorFord]

I'd just like to apologize in regards to the way this ticket was handled, while the actual offending user which was unrelated to your account that was causing the issues with mail on the server was disabled and suspended; this information was not ever made very clear to you in our responses. I do apologize that this was not made more clear for you. I've updated your ticket with the relevant information on this issue. Please let me know if you have any further questions or concerns I can address. Thank you.

[bqikbill]

Originally Posted by GatorFord

.... Please let me know if you have any further questions or concerns I can address. Thank you.

Yes, as a matter of fact, I do.

When did this action occur? Am I to assume it happened on the third time, or did it happen on the second offense and the third was yet another problem?

Why wasn't the offending user stopped the first time, instead of the admin people just clearing the queue and letting it go, thereby causing me to suffer three multiple hour outages and irate customers?

Are there rules in place that tell admin people how to handle a situation like this and they were just ignored, or are you now writing rules and procedures to make sure this won't happen again?

Are there any software sub-routines/fixes/patches/hacks that can be/have been implemented to prevent this in the future?

In other words, what are my assurances that the same thing won't happen again for the next three nights with the same user signing up with the same host under a different name and doing the same thing??!!

If you can't give me any assurances, how am I supposed to give any to my customers?

[GatorFord]

Question : When did this action occur? Am I to assume it happened on the third time, or did it happen on the second offense and the third was yet another problem?

Answer : The user in question was actually suspended with messages removed to the queue several hours prior to your ticket being submitted, however the issue with this particular user was that while the remove messages command was issued to exim to remove these messages, exim's spool filesystem was actually consuming 100% of the inodes for the exim spool, so that the exim remove message command did not fully remove these and they had to be cleared manually. This is very uncommon which is why I believe this wasn't addressed at the first report.

Question : Are there rules in place that tell admin people how to handle a situation like this and they were just ignored, or are you now writing rules and procedures to make sure this won't happen again?

Answer : We do have written policies in place in regards to abusive mail users and the proper action was taken. As previously outlined this was an issue which probably occurs less than 1% of the time where the entire partitions inode limit is reached. I'm adding this into our documented procedure for these so that this is also checked when offending messages like this are cleared.

Question : Are there any software sub-routines/fixes/patches/hacks that can be/have been implemented to prevent this in the future?

Answer : Our mail services do have custom configurations in place with limits and reporting in place to enforce and address abusive mail users. In this case the exim spool was completely full which prevented the mail from being removed without manual intervention.

Question : In other words, what are my assurances that the same thing won't happen again for the next three nights with the same user signing up with the same host under a different name and doing the same thing??!!

Answer : I will continue to monitor this server for any inode limit abuse but it is currently at 1% usage and I don't see any abusive users causing the inode limit to be increased at all at this time. I don't see any reason to believe that this behavior will continue currently.

Again, I do apologize in regards to the issues you had in this ticket, and I'm 100% with you in that some of the responses on this ticket were not 100% clear and did not fully resolve the issue. I'm taking the necessary steps on my end to make sure this is addressed. Please let me know if there's anything else I can help you with.

[bqikbill]

Originally Posted by GatorFord

Please let me know if there's anything else I can help you with.

Yes, as a matter of fact, there is!

But first of all, THANK YOU for the answer. I'm not Linux literate, but I know what the fat system is in DOS/Win-doze, and I assume the file system in Linux performs some similar function in terms of recording where files are stored. If I'm understanding you correctly, just the file system, (or functions of it), were taking up all available records (or space) for the entire partition allocated to it. That must have been a LOT of spam messages, and I can see why it might not have been caught upon first examination.

My final issue, though, is about why I had to go to such lengths to GET an in-depth answer. Now, I DO understand that most of the end users you host, (and some percentage of the resellers), do not even know what a file system is or does, nor do they care, (or need to!). So that part of the explanation would be lost on them.

But this is the first full explanation I've gotten of what happened, how it happened, how unusual it is, and why it's not likely to happen again any time soon. And that's the part I needed in order to pass similar assurances on to my customers.

A suggestion would be for HG to assign some sort of rating to resellers whereby they can bypass "level 1" support, (or whatever it's termed there), to speak to someone who can actually answer their questions if they deem it necessary.

The benefit to HG would be three-fold:
A. Obviously, resellers who are less disgruntled with your service
B. Time savings. This whole exchange would have taken less than 5 minutes over the phone
C. No airing of "dirty laundry" in public.

In fairness to HG, there aren't many organizations today that would even allow this post and its follow-ups to be public, (well, it's not REALLY public ... you have to join FIRST before you can read it, but still ...).

It's is a shame though, (and has been a gigantice waste of EVERYONE'S time), to have to go thru this to get an answer that should have been proffered in the intital conversation.

But Ford, thanks again for taking the time to give a complete explanation.

BTW, GatorFord is actually a car dealership down here in my neck of the woods! http://www.gatorford.com/ They oughta send you a t-shirt for the free advertising!

[GatorFord]

In regards to the first issue, yes, basically when inodes are completely full for a partition it's because no more file or directory descriptors are available for the filesystem, and this is exactly what occurred. The offending user who was actually the source problem of this had an open script and has been suspended and notified as such.

Secondly, I'll agree with you; you really should never have to go to this length to get an adequate response; I believe that support should have caught this sooner and been able to provide you with a better answer for each response. If you see an issue where you don't think you're getting the adequate level of help, please PM me the ticket or chat I'd be more than willing to review and make sure everything is being handled properly and if not, take appropriate action on my end.

In regards to the third question about bypassing tier 1 support, we generally do not do this unless there are extreme circumstances or very custom configurations which our Level 1 technicians would not be familiar with. I'd really prefer to get any issues or misunderstandings with our Level 1 department fully cleared up internally, as an immediate escalation may cause an unwanted delay in ticket response since there are a lower volume of Level 2 and Level 3 techs.

Thanks for the laugh on the GatorFord dealership, I might have to ask them if I can use their logo for my forum avatar