How to Troubleshoot Common Site Issues on a Linux Server

If the performance of your Linux server isn’t up to par, there probably is a problem at the root of the problem that has to be fixed. At some point, everyone encounters issues with their website or web server. You can solve these issues as fast and effectively as possible by learning where to check and which elements are the most likely offenders when you encounter a problem.

You can find all the necessary information you need to troubleshoot common site issues on a Linux server in our knowledge base.

To resolve the most typical network problems with a Linux server, adhere to the instructions outlined below.

First, check What Sorts of Issues Are Common?

When attempting to launch your website, the vast majority of issues you’ll run into fall into a predetermined range.

Here is a list of things to consider, however, we will discuss these in more detail in the sections below:

• Has your web server been set up?

• Does the web server have an uptime?

• Are your web server configuration files’ syntaxes correct?

• Are the configured ports open (i.e., unblocked by a firewall)?

• Are your DNS configurations pointing you in the right direction?

• Does the doc root reference where your files are stored?

• Are the correct index files being served by your web server?

• Are the file and directory structures’ permissions and ownership set up properly?

• Is your database backend operational, if you have one?

• Can your website effectively connect to the database?

These are some of the typical issues that site managers face when a site is malfunctioning. By examining the log files of the various components and consulting the error pages displayed in your browser, the precise problem can frequently be pinpointed.

Further, we’ll go over each of these scenarios in more detail below so you can make sure your services are configured properly.

Analyze the logs.

Try to inspect the logs of your web server and any clusters before attempting to find a problem blindly. These will often be in a service-specific subdirectory of /var/log.

For example, by default, the logs for an Apache server operating on an Ubuntu server are stored in /var/log/apache2. To find out what kind of error messages are being generated, look through the files in this directory. Likely, the logs from any problematic database backend will also be kept in /var/log.

Whether the processes themselves provide you warning messages whenever the services are started is another item to look at. If you try to access a website and encounter problems, the error page may also include useful information (although not as specific as the lines in the log files).

Try using a search engine to look for pertinent data that can appropriately lead you. To locate other instances of the same problem, you can frequently find it useful to immediately put a portion of your logs into a search engine. You can continue you’re troubleshooting using the procedures listed below.

Have you set up your web server?

A web server is usually the first item you’ll need to properly serve your web pages. You may not always need to install a dedicated web server because your web pages may be provided directly by a Docker container or another application, but most deployments still require at least one.

Before arriving at this point, the majority of users will have installed a server, however, there are some circumstances in which you might have mistakenly uninstalled the server while carrying out other package actions.

If you need to install the Apache web server on a Debian or Ubuntu computer, type:

sudo apt-get update

sudo apt-get install apache2

The Apache process on these platforms is known as apache2.

If you want the Nginx web server and are using Ubuntu or Debian, try typing:

sudo apt-get update

sudo apt-get install nginx

These systems refer to the Nginx process as nginx.

If you want to use the Apache web server and you are using RHEL, Rocky Linux, or Fedora, you can type:

sudo dnf install httpd

The Apache process on these systems is known as httpd.

You can type this to utilize Nginx if you are running RHEL, Rocky Linux, or Fedora. If you are logged in as root, once more remove the “sudo”:

sudo dnf install nginx

These systems refer to the Nginx process as nginx. Nginx has not launched automatically after installation on these RPM-based distributions, in contrast to Ubuntu. Learn how to start it by reading on.

Do you have a running web server?

Are you certain your server is functioning now that it has been installed?

There are many techniques to determine whether the service is active or not. Using the netstat command is one approach that works on most operating systems.

You may find out all the processes using the server’s ports by running netstat with the -plunt parameters. The name of the process you’re looking for can then be found in the netstat output using grep:

sudo netstat -plunt | grep nginx

Output

tcp        0      0 0.0.0.0:80         0.0.0.0:*        LISTEN      15686/nginx: master

tcp6       0      0 :::80                :::*                 LISTEN      15686/nginx: master

The name of the web server process on your server can be substituted for nginx. A line similar to the one above indicates that your process is active. If you don’t receive any output, either you’ve asked about the wrong process or your web server isn’t up and functioning.

You can start your web server using the init system of your Linux distribution if it isn’t already operating. The majority of background-running software will register with the init system after installation so that you can start and stop it programmatically. The majority of distributions now employ the same systemd init system, which offers the systemctl command.

For instance, you may type the following to launch the nginx service:

sudo systemctl start nginx

You can use netstat once more to confirm that everything is in order after your web server has started.

Is your web server configuration file’s syntax correct?

The inability of your web server to start is typically a sign that your configuration files want attention. The syntax of Apache and Nginx must be strictly followed for their configuration to be correctly parsed.

Typically, a subdirectory of the /etc/ directory named after the process contains the configuration files for system services.

On Ubuntu, for instance, you may type: to access the main configuration directory for Apache.

cd /etc/apache2

On RHEL, Rocky, and Fedora, the Apache configuration directory also displays the process’s RHEL name, which is:

cd /etc/httpd

The configuration will be dispersed among numerous files. A service that is attempting to start but fails to do so will typically output errors that refer to the configuration file and the line that contains the issue. You can begin looking into that file.

Additionally, every one of these web servers offers a mechanism to check the configuration syntax of your files.

The apache2ctl or apachectl commands can be used to verify your configuration files for syntax issues if you’re using Apache:

apache2ctl configtest

Output

AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1. Set the ‘ServerName’ directive globally to suppress this message

Syntax OK

Every message printed before that was a minor error or a warning, and “Syntax OK” basically implies there are no significant faults stopping the server from running. Could not reliably establish the server’s fully qualified domain name in this instance refers to an out-of-the-box Apache configuration on a server that has not yet been configured with a domain name but that should still be reachable by its IP address.

You can perform a similar test using an Nginx web server by typing:

sudo nginx –t

Output

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

You would receive a notice similar to this if you left a semicolon off of a configuration line in /etc/nginx/nginx.conf, which is a common mistake for Nginx configurations:

sudo nginx –t

Output

nginx: [emerg] invalid number of arguments in “tcp_nopush” directive in /etc/nginx/nginx.conf:18

nginx: configuration file /etc/nginx/nginx.conf test failed

Because Nginx searches for a semicolon to finish statements, there are too many arguments. If it doesn’t, it moves on to the next line and reads that as more support for the previous line.

These tests can be used to identify syntax issues in your files. As soon as you can get the files to pass the test, fix the issues it mentions.

Are the configured ports open?

Web servers typically utilize port 443 for HTTPS traffic encrypted with TLS/SSL and port 80 for HTTP web traffic. These ports must be open in order for users to access your website.

By using netcat on your local machine, you may check if your server’s port is open.

You must enter the IP address of your remote server and specify the port to check, as in the following example:

nc -z 111.111.111.111 80

This will verify that the server located at 111.111.111.111 has port 80 open. The command will immediately return if it is open. If it is closed, the command will keep trying in vain to establish a connection. The procedure can be stopped by hitting CTRL+C in the terminal window.

You need to check the setup of your firewall if your web ports are not accessible. It could be necessary to open port 80 or port 443.

Are your DNS Settings Sending You in the Right Direction?

You may need to check your DNS settings if you can access your site via its IP address but not via a domain name that you’ve registered.

host -t A example.com

Output

example.com has address 93.184.216.119

Your server’s IP address must match the line that is given to you. If you need to check an “AAAA” record (for IPv6 connections), you can type:

host -t AAAA example.com

Output

example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7

Remember that depending on your domain name registrar, any modifications you make to your DNS records may take some time to take effect. Checking when your DNS changes have taken effect globally using a website such as https://www.whatsmydns.net/ might occasionally be useful. After a change, you can get erratic responses from these queries since your request frequently reaches several servers that aren’t all current at the same time.

Ensure that your configuration files manage your domain appropriately.

Check your Apache virtual host files or the Nginx server block files to make sure they are set up to respond to queries for your domain if your DNS settings are right.

Your virtual host file in Apache might resemble this:

/etc/apache2/sites-enabled/000-default.conf

<VirtualHost *:80>

ServerName example.com

ServerAlias www.example.com

ServerAdmin [email protected]

DocumentRoot /var/www/html

. . .

Any requests made to the virtual host on port 80 for the domain example.com will be answered.

An equivalent chunk in Nginx may resemble this:

/etc/nginx/sites-enabled/default

server {

listen 80 default_server;

listen [::]:80 default_server ipv6only=on;

root /usr/share/nginx/html;

index index.html index.htm;

server_name example.com www.example.com;

. . .

These two blocks are set up to react to identical kinds of queries by default.

Does the Document Root Indicate Where Your Files Are?

If your web server is pointing at the correct file location is another thing to think about.

Each server block or virtual server in Nginx or Apache is set up to point to a particular port or local directory. When you try to visit the page, the server will throw an error if this is configured wrong.

The DocumentRoot directive in Apache is used to configure the document root:

etc/apache2/sites-enabled/default

<VirtualHost *:80>

ServerName example.com

ServerAlias www.example.com

ServerAdmin [email protected]

DocumentRoot /var/www/html

. . .

The line here instructs Apache to search the /var/www/html directory for the domain’s files. If your files are stored somewhere else, you will need to change this line to point to the proper place.

The root directive in Nginx configures the following:

server {

listen 80 default_server;

listen [::]:80 default_server ipv6only=on;

root /usr/share/nginx/html;

index index.html index.htm;

server_name example.com www.example.com;

. . .

In this installation, Nginx searches the /usr/share/nginx/html directory for files for this domain.

Are the Index Files being served by your Web Server Correct?

You may have your indexes configured wrong if your document root is accurate but your index pages are not being served correctly when you visit your site or a directory location on your site.

Many web servers still serve index files by default, depending on the complexity of your web applications. Depending on your settings, either an index.html or an index.php file is typically used for this.

You might notice a line in your virtual host file for Apache that specifically specifies the index order to be utilized for a given directory, like this:

/etc/apache2/sites-enabled/default

<Directory /var/www/html>

DirectoryIndex index.html index.php

</Directory>

This indicates that when the directory is served, Apache will seek a file with the name index.html first, and if the first file cannot be found, attempt to serve index.php as a backup.

By making changes to the mods-enabled/dir.conf file, which establishes the server’s defaults, you can modify the order in which index files will be served for the entire server. Make sure you have an index file in your directory that corresponds to one of the choices in your file if your server is not serving an index file.

The index directive in Nginx is used as follows to do this:

/etc/nginx/sites-enabled/default

server {

listen 80 default_server;

listen [::]:80 default_server ipv6only=on;

root /usr/share/nginx/html;

index index.html index.htm;

server_name example.com www.example.com;

. . .

Are the file and directory structures’ permissions and ownership set up properly?

The web server must be able to read the files and have access to the directories where they are housed for it to deliver files appropriately. The ownership and permissions of files and directories can be used to control this.

The directories containing the content must be executable and readable by the user account connected to the webserver to read files. Apache and Nginx are operated under the www-data group’s www-data user on Ubuntu and Debian.

Apache is run by the user apache, a member of the apache group, on RHEL, Rocky, and Fedora. Nginx is used by the nginx group and is run by the user nginx.

You can analyze the files and directories you are hosting by taking into consideration:

ls -l /path/to/web/root

The web user or group must be able to access and execute the directories, and the files must be readable concerning reading content. The folders must also be writeable, and the files must also be writable in order to upload, write, or alter the material.

You can use the chown command to change a file’s ownership:

sudo chown user_owner:group_owner /path/to/file

A directory may also be subjected to this. By supplying the -R flag, you can modify the ownership of a directory and all of the files included within it:

sudo chown -R user_owner:group_owner /path/to/file

Are your configuration files used to restrict access?

It’s also possible that the web server settings are set up to prevent access to the files you’re attempting to serve.

This would be set up in Apache either through an.htaccess file contained in the directory itself or in the virtual host file for that site.

There are several different techniques to limit access to these files. In Apache 2.4+, directories can be limited in the following ways:

/etc/apache2/sites-enabled/default

<Directory /usr/share>

AllowOverride None

Require all denied

</Directory>

These limitations will be contained in your server blocks or main config files and will be implemented by Nginx as refuse directives:

/etc/nginx/sites-enabled/default

location /usr/share {

deny all;

}

Is your database backend operational, if you have one?

Make sure it is up and accessible if your website depends on a database backend like MySQL, PostgresSQL, MongoDB, etc.

The same method you used to ensure the web server was operational can be used to accomplish that. Once more, you may use grep and netstat to scan across active processes:

sudo netstat -plunt | grep mysql.

Output

tcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

The service is active on this system, as you can see. When looking for your service, be certain you are using the correct name.

Searching for the port that your service uses is an alternative. You can check your configuration files or consult the documentation for your database to learn what port it operates on by default (MySQL’s default is 3356).

Does your site have a successful connection if you have a database backend?

Checking to check if you can connect properly is the next step in debugging a database backend. In most cases, this entails looking through the files that your website reads to discover the database data.

For example, a file called wp-config.php contains the database connection information for a WordPress website. For your website to connect to the database, make sure the DB NAME, DB USER, and DB PASSWORD are accurate.

By manually attempting to connect to the database on the command line, you may determine whether the information in the file is accurate. The majority of databases will support MySQL-like syntax:

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

You might need to change your databases’ access permissions if you can’t connect using the settings you found in the file.

If everything else fails, recheck the logs.

Although reviewing the logs need to be your first move, doing so is an excellent final resort before seeking more assistance.

You will receive more pertinent assistance more quickly if you provide log files and problem messages if you have exhausted your options for troubleshooting alone. Experienced administrators will probably have a good sense of what is happening if you provide them with the bits of information that they need.

To Conclude

With any luck, these troubleshooting suggestions have assisted you in identifying and resolving some of the more typical problems website administrators encounter while attempting to get their sites up and running.

Stay tuned for more updates! Happy Learning!