Troubleshooting methods for Web Servers and background services running on Linux Cloud Servers
This tutorial explains troubleshooting methods and strategies in the events about Linux Cloud Server is not able to connect to your web server, database, or other services running on the Linux Cloud Servers.
Before beginning this tutorial, the Cloud Server's root access is the prerequisite for this. In other words, the server's root password must be available, so as to perform operations.
Checking the Service Status
During the process of troubleshooting, it is quite normal to check the status of the service running in the background/foreground. This can be done through the below command.
# systemctl status <service-name>
Examples:
Restarting the Service
If the process is not running you may try to restart the process using the command.
# systemctl restart <service-name>
Example:
Enabling the Service
If you wish to have the process to survive a server reboot, i.e you would like to start the service automatically when a server reboot is performed, you would require to use the command.
# systemctl enable <service-name>
Examples:
Disabling the Service
Firstly if the service is running, it can be stopped.
# systemctl stop <service-name>
And then disable the service.
# systemctl disable <service-name>
Examples:
Checking the IP address and ports
While performing troubleshooting, it may require checking if any process is listening to any ports or it may be bound by a public IP address, you can use the ss command also called socket statistics command which provides the lists that are currently accessing, Classic example is given below:
# ss -atpu
Analyzing Server logs
For any system/service-related issues it is always recommended to check the server logs to find out more about the issues. If any services don’t start normally, for more insights check the server logs.
To check the contents of the system, use the command
journalctl.The server log location for Ubuntu/Debian will be on
/var/log/syslog.CentOS streams log location will be on
/var/log/messages.
A typical Journalctl output will be described as below:
# journalctl -xe
Here are some examples of how to verify the logs:
# tail –f /var/log/syslog
# tail –f /var/log/messages
Checking the Firewall Status
When the service is running without any issues, and still having trouble regarding the connectivity, it is likely the firewall may be interfering with the connections. The below command will help you list the relevant rules.
# iptables -L
To check if it is firewalld or ufw, you would be able to view it by the following commands:
# ufw status
OR
# firewall-cmd --state
For troubleshooting, you can also temporarily disable your firewall to test if it is interfering with your connections.
Troubleshooting the Web Server
Since the webserver troubleshooting is complicated, a standard troubleshooting policy needs to be adopted. This has to identify the correct server problem. Therefore, follow the steps:
Check if the services are running correctly and proceed.
If the webserver is returning a specific error code, some of the HTTP status codes are given.
The five classes include:
1xxs: Webserver status code indicating browser request still on
2xxs: Success server status code
3xxs: Server redirection status codes indicated
4xxs: Client error codes citing the problem with the request.
5xxs: Server error codes citing requests were accepted, but an error on the server prevented the fulfillment of the request.
When the webserver returns with an error code, the troubleshooting steps will vary according to the code returned. Further details will be available from the web server logs. Here are commands that help you find the web server logs:
For Ubuntu/Debian:
# grep ErrorLog -r /etc/apache2
For Centos/Fedora/RHEL:
# grep ErrorLog -r /etc/httpd
For Nginx:
# grep error_log -r /etc/nginx
Troubleshooting the Database
Common issues that may encounter upon that the database process may not start because of the disk reaching full occupancy. The below command shows the storage status:
# df -Th
Once it is checked, as a part of freeing the disk space it will require removing the files that may not be required.
Further, upgrading the Layerstack Cloud server plan is recommendable if most of the storage files are required and essential.
Now, in case of Database running is experiencing some delay and it is affecting the Cloud Server performance, as a part of troubleshooting MySQL can be tuned up or optimized using scripts. The script is given repo:
https://github.com/major/MySQLTuner-perl
Thus with the help of a database administrator, the configuration can be tweaked and tuned up.
Related Tutorials
