One of the most common uses of the server online is to host websites . This is made possible by software that serves content http among other things. In this post I will explain some tricks to detect and repair problems in the web service systems are GNU/Linux . For simplicity we will focus on apache that is most commonly used.

Usually the first news we have when there are problems on the web server is that browsers are not able to view the contents. Before entering the server should check whether the problem is DNS and because the domain name does not resolve to the IP of our web server. This can be seen using applications such as ping, host, nslookup dig, etc. depending on which we have at hand.
If we are sure that the DNS domain works and points to the ip web service, we as administrators to access this and try to figure out and solve whatever the problem.

Before entering the rag, as first information we say that the http protocol working on port 80 of our server. This is an important fact because knowing we can easily obtain data on the processes that are running on.
Once inside, the first thing we do is use the “netstat” command that displays a list of ports and connections established on our server:

As shown, using along with “grep” command, to filter by “LISTEN” and “80” shows us if there is a process listening on port 80, and uses the service “httpd”. If you were to remove the “| grep LISTEN” command we also show the connections that are still active in that port, among them we can find established connections, pending pending or closed.

In addition, we also have a command called “lsof” that can show us even more information about users and number of running processes. This command displays information about open files on the Linux system Linux since everything works through files for us is very useful. In this case we need to tell that look open files related to port 80 and we will do this by specifying “-i 80” within the system being as administrator users:

This above is a normal output of a server where no one is watching hosted pages. Here we can see how the user running the process is “apache” that there is a father and 6 children process processes waiting for requests to come to serve the content. If someone look up a page where they appear more “LISTEN” now appears, indicating the source of the connection among other things.

If our server we see no processes running on port 80 with any of the above commands, it is indicative that the web service is not functioning as it should and therefore we will have to start it again. This it is depending on which Linux distribution will we use it using a name or other distributions based on Redhat and Centos is made with “httpd” and those based on Debian as Ubuntu, with “apache2”

In our case we use httpd because it is a Centos, and as the web server is booted correctly, so we would just check now if there are processes running and try to visualize the sites again in the browser.

In the case unbootable may show us an error message that would be analyzed in detail to determine exactly what happens, as there are many possibilities. We should also look at the error log to see if you have left any indication message. This can be done with the cat or tail command or any console text editor, such as vim or nano, or emacs.

A very useful application of the above is “tail” as with the “-f” behind allows us to see the logs in real time, for example:

tail -f /var/log/httpd/error_log

If we leave it running on a console and the other try to start the service, or access the browser we can see errors in real time, which will be very useful.
Sometimes the web server appears to be booted and operating normally with its processes to listen, but still the websites do not work properly and do not show any content in the browser.
In these cases to see what happens priority as noted above is to look at the error log, which normally displays detailed information on the problems that prevent operation. After displaying the error, unless we know that it is, it is normal to use a search engine like Google for information about this error and some way to fix it. If no message still appears what should be done is to stop all instances of the web server and launch it in debug mode:

httpd -e DEBUG

With this if we should be able to see any internal error to help in its resolution. In any case if after following all these steps do not manage to run your web server we recommend that you get in the hands of professionals who can resolve the issue quickly and efficiently.
Finally we will put a list of the most common mistakes that we can find the time to lift a web service dropped and some ideas of how to fix them. Errors that can go in the log when the problem is the web configuration or the code we leave for another back entrance.

1. “make_sock: could not bind to address 0.0.0.0:80 no listening sockets available”
If this error appears when starting the web service is probably already is operating as there is something listening on port 80. If we have problems we try to stop it first with a “service httpd/apache2 stop”, but still still dating the same mistake should kill the process that is occupying port 80, bringing the number pid first described above with lsof or netstat command and using the “kill -s 9” pid command “to force it to stop.

2. “No such file or directory: apache2: Could not open error log file /var/log/apache2/error.log”
With this error the web server indicates that the start could not write in the log that is assigned in its configuration, either because the folder does not exist, because it can not create the file or because the file exists but permits/users are not correct. To solve it we must analyze all these factors and allow the web server user can write to that file and re-launch the process.

3. “Starting httpd: Syntax error on line xxx of /etc/httpd/conf/httpd.conf: DocumentRoot must be a directory”
Sometimes the error redirects us to an exact point configuration web service. In that case we will check the configuration file in question, and analyze that may fail exactly on the line indicated. In this case the “DocumentRoot” which is the root of the web server was not accessible by this, being similar to point 2 solution.