TextDrive: Not Our Fault
I continue to have something of a love/hate relationship with my web host, TextDrive. It’s a great nerdy shared hosting company. Great because they give you a lot of control over your domain (control I don’t really even need), and let you play around with various web technologies (if you ever want to — as of yet I haven’t gotten the motivation).
They also have a few individuals working there that just have a bad attitude. Consider Jan Isley’s update in the TextDrive system status blog (very cool in that you can subscribe to the RSS and get updates on what’s going wrong with the servers — somehow I doubt you can get this kind of information at most other hosts):
Another problem, sadly all to frequent, is users moving, renaming, deleting, etc the basic virtual server container created for their domains, especially but certainly not limited to the logs directory. We give users a lot of power and control over their environment here. That is a dangerous thing. Too dangerous, it seems sometimes. Folks, if you are going to draw outside the lines, play outside the box, the onus is on you to not break things. When Apache thinks a virtual container’s root or logs directory has gone, Apache quits. And why should it not? Please, by all means, color outside the lines. But know what you are doing and know that you may break things for everyone when you do not. This is not new. This is not rocket science. Play nice.
Let’s consider what old Jan is telling us here: We trust you, dear customers, but you’re ruining the party for the other people on your server by screwing up. By the way, it’s not our problem.
Yes, TextDrive, it is your problem. And no, Apache should not quit (and bring down every single customer on the server). Maybe that’s appropriate behavior for a dusty BSD box hosting web servers in your home office, but it’s not appropriate behavior for a professional web host. We’re paying you for a certain level of service. It’s not a valid excuse to say, “Oh, sorry, but one of your fellow users broke it,” particularly when things like this seem to happen once a day to at least one machine. (There are good and bad sides to reading about each and every server problem, most of which don’t actually affect me.) You’re smart kids, and I’m sure that you could spend maybe 30 minutes hacking Apache to do something more graceful than take its toys and go home when something like this happens.
A more frequent problem is a process spinning out of control and eating up file handles or processor time or memory. Is there no way to limit a user’s file handles and keep this from happening? Surely there’s some way to do this. It’s not like they’re running Slackware Linux — this is FreeBSD!
It’s great that TextDrive allows such freedom on their machines, but they also need to maintain a level of service. Blaming their downtime on customers is unprofessional. For as friendly as their President Jason is, representatives of the company like Jan could stand to read How To Win Friends and Influence People.
This site is hosted at TextDrive. See my Uptime Statistics.