Now that you’re in your ssh session and know how to navigate the filesystem, can view the contents of folders, and can check the manual for built-in Linux apps it’s time to do some actual work. We’re here to troubleshoot some errors that we’re experiencing on our webserver. In this example we’re using NGINX and an Apache Tomcat server.

The default directories for these apps are /etc/nginx and /opt/tomcat. Our webserver keeps displaying a 500 internal error when we look at our network console, let’s see how we can check out if NGINX has any ideas what’s going wrong. While you may intuit that the NGINX log files should be in /etc/nginx/logs or something similar you’ll find that they actually exist in /var/log/nginx. Most logs are, perhaps unsurprisingly, found in the /var/log directory.

Armed with your knowledge from the previous blog post you confidently navigate to the NGINX logs. cd /var/log/nginx. No errors, the path you see is correct, let’s see what’s in the folder. ls -l you enter to see a massive wall of different log files. I’ll let you in on a little secret, the one we’re looking for is called ‘error.log’.

OK – we’ve located the file, we didn’t believe we’d get this far but here we are. Now what? The last blog post said nothing about this, I can just move around and see what’s in my folders. How do I now see what’s in the actual file? There are a few ways you could accomplish this. Firstly, you could open the file in a shell-based text editor live Vim, Emacs, or Nano. These will likely already be installed on the machine already. To open the error.log file you would simply type vim error.log.

It’s taking a while to load… We’ve run ls -l previously so we can have a look at how big the error.log file is. For big log files it’s not a good idea to load the entire contents into a text editor. Our file is big, so we’re going to approach checking it out in a different way. Using the tail command we can see the last lines of the file. tail error.log we input, confident that we’ll get a result.

We have a result, but it’s only the last 10 lines of the file, and they’re all part of a stack trace. Not very useful. By using the man we can find some flags to add to the tail program. We’ve found that using -n will allow us to select how many lines from the bottom of the file we want to see. We enter tail -n 100 error.log. Fortunately, in this example it gives us enough information to show a senior dev so they can fix the problem.

Read Help! I’ve Had To SSH Into A Linux Box For The First Time (Part 3).