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:
(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 0.0.0.0:80
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:
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:
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!