Troubleshooting Using Logs

Troubleshooting Using Logs

Troubleshooting Using Logs is part of the Log Management section of the Ubuntu administration roadmap. This guide focuses on the practical checks, commands, and verification habits needed for this specific task.

Logs tell the story of what happened on the server. Good administrators read logs before guessing.

Troubleshooting Using Logs is an operational task. Connect the command you run with the service, file, user, network path, or storage layer it affects.

What you will learn

• How Troubleshooting Using Logs fits into Ubuntu administration.
• Which commands or files are involved.
• How to inspect the current state before making changes.
• How to verify the result after the work is complete.

Before you begin

Start in a lab or staging system when possible. Confirm the Ubuntu version, your access level, and the current state before making changes.

lsb_release -a
hostnamectl
whoami
pwd

Why this matters

Troubleshooting Using Logs matters because it affects how reliably and safely the server can be operated. A careful administrator checks the current state, changes one thing at a time, and verifies the outcome.

Think like an administrator: inspect first, change one thing at a time, verify the result, and keep a rollback path.

Quick reference

Step-by-step lab

Use the lab below to practice Troubleshooting Using Logs in a controlled way. Run the inspection commands first, then make one small change, and finally verify the result.

Step 1 - Inspect the current state

Start with read-only commands. Your first job is to understand the server before changing it.

journalctl -n 50 --no-pager
journalctl -p err -n 30 --no-pager

Step 2 - Check related services, files, or resources

Most Ubuntu topics connect to a service, package, file path, user, network socket, or log. Use the next command to look at the related layer.

ls -lh /var/log

Step 3 - Make one controlled change in a lab

Only after you understand the current state should you make a change. In production, avoid combining many changes in one session. In a lab, you can experiment more freely, but still keep notes.

# Example lab note
# 1. What did I check?
# 2. What did I change?
# 3. What output proved the result?
# 4. How can I undo it?

Step 4 - Verify and record the result

Verification is the difference between guessing and administration. Run the same inspection commands again and compare before and after output.

journalctl -n 50 --no-pager
journalctl -p err -n 30 --no-pager
ls -lh /var/log

Commands to practice

Run these commands in a test VM first. Read the output carefully and compare it with your own system.

journalctl -n 50 --no-pager
journalctl -p err -n 30 --no-pager
ls -lh /var/log
sudo tail -n 50 /var/log/syslog 2>/dev/null
sudo logrotate -d /etc/logrotate.conf

Example output

Jun 09 server systemd[1]: Started OpenSSH server.

How to verify your work

Do not stop after a command finishes successfully. A command can exit cleanly while the service, application, or user workflow is still broken. Verify from multiple angles.

systemctl --failed
journalctl -p warning -n 30 --no-pager
df -h
free -h

Visual explanation

Troubleshooting workflow

If something does not work, avoid random commands. Move through the layers in order. This keeps the investigation calm and makes your notes useful for future incidents.

1. Define the exact symptom. What is failing, and who is affected?
2. Check whether the problem is recent. Look for changes in packages, config, users, networking, or storage.
3. Inspect service status and logs before restarting anything.
4. Test one hypothesis at a time.
5. Keep a note of every command and result.
6. When fixed, write the root cause and prevention step.

date
uptime
systemctl --failed
journalctl -p err -n 50 --no-pager
ss -tulpn
ip route

Production notes

Before applying Troubleshooting Using Logs in production, confirm access, backups, monitoring, and rollback steps. Watch logs immediately after the change.

• Take a backup or snapshot when the change can affect data or access.
• Keep a rollback command or config copy ready.
• Tell stakeholders what service could be affected.
• Apply the change during a low-risk time if possible.
• Watch logs immediately after the change.

Common mistakes

For Troubleshooting Using Logs, slow down and ask: what am I trying to prove, where is the configuration, where are the logs, and what does success look like?

• Skipping the baseline check before making a change.
• Running commands without reading the paths and service names.
• Changing multiple things at once.
• Not checking logs after the change.
• Not documenting the result.

Summary

Troubleshooting Using Logs is a practical Ubuntu administration topic because it connects concept, command output, logs, and operational judgment. The more you practice this workflow, the easier it becomes to work on real servers without panic.

Use the commands above as a starting point, but always adapt them to the server in front of you. Check first, change carefully, verify clearly, and document the result.