Editing Files & Reading Logs

Why Logs Are Your First Stop

When something goes wrong on a server — a web application returns errors, a service fails to start, a user cannot authenticate — the first thing you do is check the logs. This is not optional. This is the standard troubleshooting workflow across every IT discipline.

The pattern is always the same:

1. Something breaks or behaves unexpectedly
2. You SSH into the server
3. You read the relevant log file to find error messages
4. The error message tells you what went wrong (or at least where to look next)
5. You investigate and fix the root cause

This applies to web servers, databases, authentication systems, networking services, cron jobs, application deployments — everything. If you cannot read and navigate log files efficiently, you cannot troubleshoot effectively. It is that simple.

Common log locations on Linux include /var/log/syslog, /var/log/auth.log, /var/log/nginx/error.log, and application-specific log files. You will encounter all of these on the job.

Creating a Realistic Log File

On a fresh VM, there is nothing interesting in the logs yet. So we will create a realistic log file to work with. This simulates what you would actually see on a server running an application.

Open a new file with nano (we will cover nano in detail in the next section):

nano app.log

Paste the following content into the editor. These are realistic log entries with timestamps, log levels (INFO, WARNING, ERROR), and messages you would actually see in a production application:

2026-04-12 08:00:01 [INFO] Application started successfully on port 8080
2026-04-12 08:00:02 [INFO] Connected to database server db-prod-01
2026-04-12 08:00:02 [INFO] Loading configuration from /etc/myapp/config.yml
2026-04-12 08:05:14 [INFO] User [email protected] logged in from 10.0.1.45
2026-04-12 08:12:33 [WARNING] Slow query detected: SELECT * FROM orders took 3200ms
2026-04-12 08:15:01 [INFO] Scheduled backup job started
2026-04-12 08:15:47 [INFO] Backup completed: 2.4GB written to /mnt/backup/daily
2026-04-12 08:22:09 [WARNING] Memory usage at 78% - approaching threshold
2026-04-12 08:30:00 [ERROR] Failed to connect to cache server redis-01: Connection refused
2026-04-12 08:30:01 [ERROR] Retrying cache connection (attempt 2 of 5)
2026-04-12 08:30:03 [INFO] Cache connection restored to redis-01
2026-04-12 08:45:22 [WARNING] SSL certificate for api.company.com expires in 14 days
2026-04-12 09:01:15 [ERROR] Disk space on /var/log at 92% - critical threshold exceeded

Save the file with Ctrl+O (then press Enter to confirm the filename), and exit with Ctrl+X. You now have a realistic log file to practice with.

nano — The Simple Text Editor

nano is a straightforward terminal text editor. Unlike vim, there are no modes to worry about. You open the file, you type, you save, you exit. That is it.

nano app.log

This opens app.log in the editor. You can immediately start typing or use the arrow keys to navigate. The bottom of the screen shows keyboard shortcuts (the ^ symbol means the Ctrl key).

The shortcuts you will use most often:

• Ctrl+O — Save the file (“Write Out”). Press Enter to confirm the filename.
• Ctrl+X — Exit nano. If you have unsaved changes, it will ask if you want to save.
• Ctrl+W — Search for text in the file. Type your search term and press Enter.
• Ctrl+K — Cut (delete) the current line. Useful for quickly removing lines.
• Ctrl+U — Paste a previously cut line.
• Ctrl+G — Open the help screen with all available shortcuts.

cat — Quick File Dump

cat (short for “concatenate”) dumps the entire contents of a file to the screen. It is the fastest way to see what is in a small file.

cat app.log

This prints every line of app.log directly to your terminal. For the 13-line log file we created, this works great — you can see everything at once.

If you want line numbers (helpful for referencing specific lines), use the -n flag:

cat -n app.log

This adds line numbers to the left of each line, making it easy to say “the error is on line 9” when communicating with teammates.

less — The Log Explorer

less opens a file in a scrollable, searchable viewer. Unlike cat, it does not dump everything to the screen at once. It loads the file and lets you navigate through it at your own pace.

less app.log

Once inside less, you can navigate with these controls:

• Arrow keys or j/k — Scroll up and down one line at a time
• Page Up / Page Down or Space — Scroll by full screen
• g — Jump to the top of the file
• G (Shift+g) — Jump to the bottom of the file
• /pattern — Search forward for “pattern.” Type /ERROR and press Enter to find all error lines.
• n — Jump to the next search match
• N (Shift+n) — Jump to the previous search match
• q — Quit and return to the terminal

Try it: open app.log with less, then type /ERROR and press Enter. You will jump directly to the first error line. Press n to cycle through each error. This is dramatically faster than scrolling through thousands of lines by hand.

tail — Watching Logs in Real Time

tail shows the last lines of a file. By default, it displays the last 10 lines:

tail app.log

You can specify how many lines you want with -n:

tail -n 20 app.log

This shows the last 20 lines. Useful when you want to see a bit more context around the most recent entries.

But the real power of tail is the -f flag:

tail -f app.log

The -f stands for “follow.” Instead of printing the last lines and exiting, tail -f keeps the file open and prints new lines as they are written in real time. It sits there, watching the file, and the instant any process appends a new line to it, that line appears in your terminal.

This is how you monitor live services. When you are deploying a new version of an application, you run tail -f on its log file so you can immediately see if something goes wrong. When a user reports an error, you run tail -f and ask them to reproduce the issue so you can watch the error appear live. When a cron job runs at 3 AM and you are watching to make sure it succeeds, tail -f is what you use.

To stop following, press Ctrl+C. This does not delete or modify the file — it just stops the tail process.

Try It — Live Log Monitoring

tail -f app.log

echo "2026-04-12 09:15:00 [INFO] Health check passed - all services responding" >> app.log

echo "2026-04-12 09:15:30 [WARNING] Request queue depth at 85% capacity" >> app.log

echo "2026-04-12 09:16:01 [ERROR] Timeout connecting to payment gateway api.payments.com" >> app.log

echo "2026-04-12 09:16:02 [ERROR] Transaction ID 8842 failed: upstream timeout after 30s" >> app.log

echo "2026-04-12 09:16:15 [INFO] Payment gateway connection restored" >> app.log

echo "2026-04-12 09:20:00 [INFO] Daily report generated: 1,247 transactions processed" >> app.log

Bonus: Quick Command Combinations

Now that you know these commands individually, here are some combinations you will see and use frequently:

# See only error lines (preview of grep, which we cover next)
cat app.log | grep ERROR

# Count how many warnings are in the log
cat app.log | grep WARNING | wc -l

# See the last 5 lines of a system log
tail -n 5 /var/log/syslog

# Follow multiple log files at once
tail -f /var/log/syslog /var/log/auth.log

Do not worry about fully understanding grep and pipes yet — those are covered in detail on the next page. The point here is to see that these commands work together. That composability is one of the most powerful aspects of the Linux command line.