You can investigate a faulty server numerous ways, but not every option will get you the answer you’re looking for. Investigating and identifying symptoms of an issue can begin to lead you to the root cause of the problem; knowing where to look is an important half of a battle. Depending on where the issue is, different commands will help you determine and debug the issue.

Here are five basic commands to diagnose an ailing Linux server.

Please note that we’re assuming you have connectivity to your server with root access. If you do not but are using Linode, LISH can help you get in.

netstat -plntu

What do you do when you know the software is running, but can’t connect to it? Netstat is one of the first tools to use to troubleshoot this common problem.

Results of running netstat will provide information on the connections going in and out of your server. Running the command with the flags ‘-plntu’ will show a nicely formatted output with what service is making use of your network, what port it’s on, its process identifier (PID), and more.

Server issues revealed by netstat -plntu typically include services using the wrong ports, or not listening at all. Resolving such issues warrants going to that service’s configuration and making a change to the right port.

iptables -nvL

Iptables are a set of rules to deal with incoming and outgoing server traffic — they’re firewall rules. This command will list your iptables, showing you any rules that could block connectivity to a previously accessible site or server, and the options added at the end will make it easier to read for most people.

One of the most common connectivity-blocking culprits is having an unexpected rule, or lack of exception, in the iptables. Perhaps a change wasn’t saved? Or maybe the domain (as opposed to IP address) input is not resolving and causing issues? Checking the iptables rules will shed light on that.

Steps to resolve issues found here can vary and will include actions such as making new rules or flushing unwanted ones. This guide can help.

free -m

This command shows information about your RAM usage. If you’re seeing a slow server, the lack of RAM could be the issue. Run this command to diagnose if that is the case.

It’s best to use this command when your server is exhibiting issues — perhaps a slow site. Any other time won’t give the full picture.

Allocating more RAM is the obvious immediate fix, but there’s more to it than that. Properly configuring whatever is exhausting that RAM will take you far toward a solution, especially if it’s affecting your site hosted on the server (proper configuration could more than double the amount of users in the server). Improved configuration depends on what’s going on in the server, but application-specific tools like Apache2Buddy and MYSQLTuner can do the diagnosis and suggest the configuration, making a solution easier for you.

htop

Top will list all running processes on your server, its PID, and the resources used for said processes. Htop will do all this, but show it on an interactive output with easier to follow bars and color-coded segments. This is not shipped on any distros by default, but a quick installation (apt-get install htop) will solve that matter.

The suite of information shown by this command can help with many issues, but I mostly use it to see where performance bottlenecks are taking place. Is the server slow? I’ll just run htop and see if the server load is high and if there’s an unexpected culprit.

Finding an issue using htop typically means you’ll need to go to the respective service’s configuration and/or logs to see if something unexpected is going on. If everything is working or configured fine but the load is still high, you may need more resources overall.

Sometimes, stranger issues, such as a stuck service that just won’t kill itself when it should or maybe a memory leak, can cause the problem. These occasions might necessitate a more immediate action, such as running a kill command accompanied by the PID of the process needing to be killed.

tail /var/log/exampleservice/example.log

This command (altered to your specific directory) gives the end (most recent) portion of the log for the identified service being checked. You can also change the number of output lines by appending the command with ‘-n 40’ or whatever number you desire.

Checking logs is critical when an issue occurs; as long as a service is setup to output to logs for errors, you will get a good indicator of what went wrong.

If the logs show your server ran out of memory (OOM) then you should check the service that caused the OOM. If it says a term is not recognized, go to the corresponding configuration and see if you’ve mistyped something. So on and so forth for each different kind of issue found.