Disk Space

Evidently, Plesk does not properly report available disk space… at least on our virtual-dedicated server from goDaddy.

I was terrified when I logged in to Plesk to find a bright red warning that I had exceeded my allotted server storage. My first thought was how is it even possible for me to be using more space than I had available. My second, and much more concerning, thought was that goDaddy was happily expanding my available storage to match my needs. Not because they are looking out for me, but because then they could stick me with a nice fat overage bill, like the cell phone companies.

Fortunately, the reality was much simpler and less costly for me. Plesk was just wrong. A quick check of my account control panel in my goDaddy account claimed that I had more storage than Plesk was reporting, which I confirmed by SSHing into my server and running the following:

df -h

The disk free command shows how much space is on each of your drives and adding the -h option prints the numbers out in GB, like us humans understand.

Plesk was under-reporting my storage by about 25%, which is obviously a significant difference when we are talking about hundreds of GB.

P.S. Happy Anniversary to my wonderful wife, Susie!

Address Already in Use

It is never fun to find out that one of your servers and the subsequent hosted websites are down.  There are a ton of reasons why websites go down, and sometimes it takes some digging to figure out the problem, particularly for a novice like me.

Today I got the word that a server was down, so immediately I pop up Firefox and punch in the URL, hoping it isn’t true.  Much to my chagrin, the little loading circle just keeps spinning…. which is typically the worst problem, because I get no feedback as to what is going on. My typical first reaction to this situation is to log into Plesk and see if I can determine the problem. No go, Plesk is not responding either. Now I know it is a server problem.

I have come to really like Tunnelier from Bitvise for my SSH client. It is free in environments with less than 5 users and has a lot of useful features. Once I was able to connect to the server, I knew that there was not an issue with the ip or DNS or something external to my box, so the next most likely culprit for the downtime is Apache.

# /etc/init.d/httpd status

The above code will tell you the status of Apache. In my case, the Apache server was stopped. Though I have found it to be rare, there have been times when Apache has stopped running or just needed to be restarted to get the web server going again. After seeing this, I immediately went for the easy fix;

# /etc/init.d/httpd start

Apache is the web server software that runs most Unix-based systems, so when it is stopped, the whole server comes to a halt. The above command line is how you turn Apache back on. Of course it was not that easy. When I ran the start command, I got the following error:

Starting httpd:
(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address
no listening sockets available, shutting down
Unable to open logs

What this error is trying to say is that there is a process already running on the server using port 80 and now Apache is trying to use the same one, but the server won’t let it because it is busy. So, it is time to find out who is using the port.

# /sbin/fuser -n tcp 80

This will use the fuser function to find any process that is running on tcp port 80 (the -n tcp 80 just specifies that we want to find tcp connections for port 80). this returned a list of processes using the port, which in my case was a single process:

80/tcp: 1421

I could have also used fuser to kill all processes running on port 80 by adding a -k and that would have been sufficient, but I wanted to know what was causing the problem to hopefully make a long term fix. Now I know who is at fault and to find out more about that process I used the following:

# top

which lists all running processes by pid. Finding the row starting with 1421, I looked all the way to the right under the Command column and found out that the process was being run by fmsmaster. Aha! fmsmaster is the process that is run by Adobe’s Flash Media Server, which I also have running on the server. Now that I know who is causing the problem, I can turn off the FMS by using its own commands:

# /opt/adobe/fms/conf/fmsmng server fms stop
# /opt/adobe/fms/conf/fmsmng adminserver stop

Now that the FMS is not using port 80, I can turn Apache back on:

# /etc/init.d/httpd start

Bingo! The server is running again, the websites are back up and the world is right again. At this point, I could turn the FMS back on, but since it is not currently being used, I can leave it off to prevent this from happening again. Had I just killed all the processes running on port 80, I would not have know who was causing the problem and it may have happened again the next time the server restarted.

The joys of running a webserver!

Running a Webserver

I am relatively new to running and managing a web server. Sure I learned some basic UNIX commands back in school and know my way around a command prompt, but I really don’t have a ton of hands-on server management experience. This is why I keep most things simple, consult or farm-out some really specific things, and fumble my way through the rest.

We maintain a few different virtual dedicated servers, a couple for clients and one for ourselves and development purposes, all running on UNIX machines with Apache, PHP, MySQL, and some version of Plesk 10. So I get to discover all kinds of fun little things that come up, which keep things interesting and let me dabble a little bit in the harder-core nerd side of my interests.

What will follow in this category is a sort of catalog of some of the interesting things that I come across and the solutions that I implement to fix or modify the servers to achieve my goals, as ‘unlofty’ as they may be :)