DEV Community

Cover image for Troubleshooting Datacenter: Resolving Apache Service Reachability On Server
Chus
Chus

Posted on

Troubleshooting Datacenter: Resolving Apache Service Reachability On Server

#tutorial #devops #linux #networking

A server was supposed to be serving web content via Apache on port 5002, anyone trying to connect was met with a "No route to host" or "Connection refused" error.

Here is a breakdown of how to investigate and eventually restore the service.

Investigating with Telnet

The telnet command in Linux is a networking tool used to communicate with a remote host using the TELNET protocol. While it was originally designed for remote login and management, its lack of encryption (sending data like passwords in plain text) has made it largely obsolete for that purpose there. For secure remote access, always use the SSH (ssh) command instead.
Today, it is primarily used as a quick diagnostic tool to check if a specific TCP port is open and reachable on a remote server.

The standard command structure is:

telnet [hostname/server_ip] [port]
Enter fullscreen mode Exit fullscreen mode

  • hostname/Ip: The address of the remote server

  • port: The target service port (e.g., 80 for HTTP). If omitted, it defaults to port 23.

To Exit/Close, Type quit at the telnet> prompt and press Enter.

SSH Into Server

To log into a remote server:

ssh username@server_ip
Enter fullscreen mode Exit fullscreen mode
  • Check Apache Status using: 
sudo systemctl status httpd
Enter fullscreen mode Exit fullscreen mode
  • If Apache wasn't Running, Start it: 
sudo systemctl start httpd
Enter fullscreen mode Exit fullscreen mode
  • If The output revealed that another process was using port 5002, causing Apache to fail with the error Address already in use.

Resolving Port Binding Conflicts

A port binding conflict in Linux occurs when a service or application attempts to listen on a network port that is already in use by another process, preventing the new service from starting.

Here is the technical workflow used to resolve binding conflicts.

  • Scan for conflict: 
[user@hostname ~]$ sudo ss -tulnp | grep 5002 
tcp LISTEN 0 10 127.0.0.1:5002 0.0.0.0:* users:(("sendmail",pid=19948,fd=4))
Enter fullscreen mode Exit fullscreen mode
  • Resolution: After identifying the conflicting Process ID (PID), terminate the process to release the bind, allowing the port to become available for its intended service (from the above sendmail is the service with pid=19948 that is conflicting with our Apache on host 5002).

To Stop the service or kill the process ID

sudo systemctl stop sendmail
# If it won't stop, kill the PID manually:
sudo kill -9 19948
Enter fullscreen mode Exit fullscreen mode
  • Start or Restart Apache: 
sudo systemctl start httpd
Enter fullscreen mode Exit fullscreen mode

Or

sudo systemctl restart httpd
Enter fullscreen mode Exit fullscreen mode

Ensure Network Access

Adjusting Network Access Rules using iptables. A running service does not guarantee external reachability if the system's firewall blocks incoming traffic.

Explicitly add a rule to allow ingress TCP traffic on port 5002. This bridges the gap between the service being "up" and the service being "accessible."

sudo iptables -I INPUT -p tcp --dport 5002 -j ACCEPT
Enter fullscreen mode Exit fullscreen mode

Final End-to-End Verification

The final stage is the verification of the fix from an external source, typically the Jump Host (a secure intermediary server used to access and manage devices in a separate, secure, or private network zone). Using curl provides a definitive test of the entire communication stack.

  • Final Test: Use the curl utility to request the server's URL 
curl http://[hostname/server_ip]:port
Enter fullscreen mode Exit fullscreen mode
  • Result: A successful return of the site's HTML content confirms that the service is running, correctly bound to the port, and bypasses the firewall correctly

Summary

  • Investigate using telnet

  • Identified and terminated the unauthorized process occupying port 5002, successfully releasing the port bind for the web service using ss.

  • Re-initialized the Apache service after verifying configuration alignment, ensuring it was successfully listening on the designated port using systemctl.

  • Updated the iptables configuration to explicitly permit external ingress traffic on port 5002, bridging the gap between local service activity and external accessibility.

  • Confirmed full restoration of the communication path via curl from the jump host, verifying that the web server is once again reachable and performing as expected using curl.

Top comments (0)