# Learn Linux Troubleshooting Through a Practical, Step-by-Step Diagnostic Workflow Linux troubleshooting is an important skill for students, system administrators, developers and anyone who works with servers. A Linux system can run applications, manage files, process network requests and support important services for long periods. However, even a well-configured system can experience problems. A service may stop responding, a disk may become full, a user may lose access to a file, or a website may become unavailable. When these problems occur, beginners often try commands randomly until something appears to work. This approach may sometimes solve a small issue, but it does not build a reliable understanding of the system. It can also introduce new problems when commands change files, restart services or modify permissions without a clear reason. A better method is to follow a diagnostic workflow. The goal is to observe the system, collect useful evidence, identify the layer where the problem exists, test one possible cause and verify the result. ![](https://cdn.hashnode.com/uploads/covers/6a7aeea44ee326a6143a875f/ded331e7-5964-4b6d-a9af-4a2f9fec6fc9.png align="center") This article explains how to develop that method through practical Linux commands and learning exercises. It is designed for learners who want to move beyond memorizing commands and understand how Linux systems behave. ## 1\. Understand the Purpose of Troubleshooting Troubleshooting is the process of identifying the reason a system is not behaving as expected. It does not begin with changing settings. It begins with understanding the symptoms. Imagine that a website hosted on a Linux server is not opening. Several different problems could produce the same result: - The server may be offline. - The network connection may be unavailable. - DNS may resolve to the wrong address. - The web server service may have stopped. - The application may be returning an error. - The firewall may be blocking the required port. - The server may have exhausted its storage or memory. Restarting the web server without investigating could temporarily hide the actual problem. If the cause is a full disk, the problem may return immediately. The first lesson is to avoid assuming that the most visible symptom identifies the root cause. A useful troubleshooting process separates three things: **Symptom:** What is the user or application experiencing? **Evidence:** What information does the Linux system provide? **Cause:** Which condition explains the evidence and produces the symptom? Keeping these ideas separate makes technical investigations more accurate. ## 2\. Record the Problem Before Running Commands Before opening the terminal, write down what is happening. A useful problem description should include: - What is failing? - When did the problem begin? - Is the issue affecting one user or everyone? - Is the failure permanent or intermittent? - Did anything change recently? - Can the problem be reproduced? For example, compare these two descriptions: "The website is not working." "The website returned a connection timeout after a configuration update at approximately 10:30 AM. The server is reachable through SSH, but the application port is not responding." The second description gives an administrator more information to investigate. Also record the exact error message. A permission-denied error, connection-refused error and timeout do not indicate the same problem. Avoid changing several settings while collecting information. When multiple changes happen together, it becomes difficult to determine which change affected the result. ![](https://cdn.hashnode.com/uploads/covers/6a7aeea44ee326a6143a875f/19dddbc1-3402-41a3-8c81-646fbdab0741.png align="center") ## 3\. Identify the Linux Environment The first technical step is to understand which system you are investigating. Run: ```bash hostnamectl ``` This provides information about the machine, including its hostname and operating system details on systems that use systemd. For kernel information, use: ```bash uname -a ``` To identify the Linux distribution, try: ```bash cat /etc/os-release ``` Check the current login account: ```bash whoami id ``` These commands help answer basic questions about the system and the current user's permissions. This information matters because Linux distributions may use different package managers, service names and default configuration paths. A command written for Ubuntu may not work exactly the same way on another distribution. Also check the system's running time and current load: ```bash uptime ``` This provides uptime information and load averages. A high load average does not automatically mean that the CPU is overloaded. It can also be influenced by processes waiting for resources. It should be interpreted together with CPU, memory and process information. ## 4\. Check CPU and Memory Usage Resource pressure can cause applications to respond slowly or stop working correctly. Start with: ```bash free -h ``` This displays memory information in a readable format. Pay attention to available memory rather than only looking at the amount shown as used. Linux uses available memory for caching, so a high usage figure alone does not prove that the system is running out of memory. To view active processes, use: ```bash top ``` The `top` command updates process information while running. It can help identify processes using significant CPU or memory resources. On systems where it is installed, another option is: ```bash htop ``` This provides an interactive view of resource usage. You can also inspect a particular process: ```bash ps aux ``` For a more focused search: ```bash pgrep -a nginx ``` Replace `nginx` with the process name you want to investigate. When a process consumes unusual resources, do not immediately terminate it. First identify what it does, whether it belongs to an application or system service, and whether it is expected to run. For learning purposes, compare resource usage before and after starting a test application. This helps build an understanding of how processes use system resources. ## 5\. Diagnose Linux Services With systemd Many modern Linux distributions use systemd to manage services. A service may be running, stopped, failed or waiting for another dependency. To inspect a service: ```bash systemctl status nginx ``` This shows the service state and some related information. To list active services: ```bash systemctl --type=service --state=running ``` To check whether a service is enabled at startup: ```bash systemctl is-enabled nginx ``` Remember that a service being enabled does not necessarily mean that it is running now. Similarly, a service can be running without being enabled for automatic startup. If a service fails, inspect its logs before restarting it. For example: ```bash journalctl -u nginx -b ``` This displays log records related to the service from the current boot. To see a limited number of recent entries: ```bash journalctl -u nginx -n 50 ``` The output may reveal missing files, configuration errors, permission problems or unavailable dependencies. Use the evidence to decide what should be checked next. Avoid repeatedly restarting services without understanding why they stopped. ## 6\. Learn to Read Linux Logs Logs provide a record of events that occur inside the system and its applications. A system administrator may use logs to investigate failed logins, service errors, scheduled tasks, application failures and hardware-related messages. To inspect recent system messages: ```bash journalctl -b ``` To display higher-priority messages: ```bash journalctl -p warning..alert -b ``` To follow new messages as they appear: ```bash journalctl -f ``` Some applications also write log files under `/var/log`. List the available files: ```bash ls -lah /var/log ``` A common learning exercise is to compare the log output before and after starting a test service. Look for timestamps, service names, process identifiers and the exact error text. Do not assume that every warning is the cause of the problem. Systems can produce warnings that are unrelated to the current issue. A good investigation connects a log entry to the time and behavior of the reported failure. ## 7\. Investigate Disk Space and Inodes Storage problems are common on Linux servers. A partition may become full because of application logs, backups, temporary files, database data or uploaded content. Start with: ```bash df -h ``` This reports filesystem space usage. However, available disk space is only one part of the investigation. A system can also run out of inodes, which are used to represent filesystem objects. Check inode usage with: ```bash df -i ``` If a filesystem has many small files, its inode usage can become high even when substantial disk space remains. To inspect block devices: ```bash lsblk -f ``` This helps identify disks, partitions, filesystem types and mount points. To review mounted filesystems: ```bash findmnt ``` When investigating a full partition, begin with the affected mount point. Identify which directories are consuming space before considering cleanup. Avoid deleting files from system directories simply because they appear large. Application logs, databases and temporary files may be actively used. A safer learning exercise is to create a temporary directory, add sample files and observe how the disk reporting tools display the changes. ## 8\. Check File Permissions and Ownership Permission errors can prevent applications and users from reading, writing or executing files. Begin by checking the current account: ```bash id ``` Then inspect the file: ```bash ls -l /path/to/file ``` For detailed metadata, use: ```bash stat /path/to/file ``` A permission listing such as: ```text -rw-r----- ``` represents the access permissions for the owner, group and other users. To understand which directory in a path is restricting access, use: ```bash namei -l /path/to/file ``` This displays permission information for each component of the path. A user may have permission to read a file but lack permission to enter one of its parent directories. That is why checking only the final file is not always enough. For more advanced permissions, Access Control Lists can provide additional access rules. Inspect them with: ```bash getfacl /path/to/file ``` The exact tools available may depend on the installed Linux packages. Before changing permissions, identify the user account that should access the resource and the minimum permission it requires. Avoid using broad permissions such as `777` as a quick fix. They can expose files to users who do not need access. ## 9\. Troubleshoot Network Connectivity Step by Step Network issues are easier to investigate when the checks follow a logical order. First, inspect network interfaces: ```bash ip addr ``` Then check the routing table: ```bash ip route ``` These commands help identify whether the system has an IP address and a route for external traffic. Next, test whether a remote host can be reached: ```bash ping -c 4 1.1.1.1 ``` A failed ping does not automatically prove that the network is unavailable because some networks block ICMP traffic. For a DNS lookup, use: ```bash getent hosts example.com ``` If a name resolves, the system has obtained an address for it. To inspect listening network sockets: ```bash ss -tulpn ``` This can help identify which services are listening on TCP or UDP ports. For an HTTP response, use: ```bash curl -I https://example.com ``` The response headers can provide useful information about whether a remote web server is responding. These checks help separate local network configuration, routing, name resolution, port availability and application-level problems. ## 10\. Use a Layered Diagnostic Method A practical approach is to investigate a problem in layers. For a website that is unavailable, the order might look like this: 1. Confirm that the server is running. 2. Check the network interface. 3. Check the routing table. 4. Verify DNS resolution. 5. Check whether the required port is listening. 6. Inspect the web service status. 7. Read the web service logs. 8. Review the application configuration. 9. Test again from the client side. The method prevents unnecessary changes. For example, if DNS resolves to the wrong IP address, restarting the web server will not fix the name-resolution problem. Similarly, changing file permissions will not solve a network routing problem. The key is to locate the layer where the failure occurs and investigate that area first. ## 11\. Change One Thing at a Time After collecting evidence, develop a possible explanation. For example: - A service may be failing because its configuration file contains an invalid directive. - A website may be unavailable because the application is listening on a different port. - A report may not be generated because the scheduled task lacks write permission. - A server may be slow because a process is using excessive memory. Test one hypothesis at a time. Before making a configuration change, save a copy of the original file. Record the change and the reason for it. After applying the change, test the affected function. If the result becomes worse, use the documented recovery plan to restore the earlier configuration. This process helps administrators understand cause and effect instead of relying on guesswork. ## 12\. Build a Linux Troubleshooting Practice Lab Students can improve their troubleshooting skills without changing a production system. Create a virtual machine using a suitable virtualization tool. Use a test account and keep important files separate from the host computer. Practice with simple scenarios: **Scenario 1: Service unavailable** Inspect the state of a test service and read its logs. Identify why it is not active. **Scenario 2: Permission denied** Create a test file with restricted permissions. Log in as another test user and observe the result. **Scenario 3: Storage usage** Create sample files and compare `df -h`, `df -i` and `du` output. **Scenario 4: Network investigation** Inspect the IP address, routing table and listening ports. **Scenario 5: Resource usage** Run a small test process and observe how system information changes. Keep each experiment independent. Take notes about what you expected, what happened and which command provided the most useful evidence. This turns Linux administration into a practical learning process rather than a collection of memorized commands. ## 13\. Turn Troubleshooting Into a Learning Routine Technical skills improve when practice is regular. Instead of studying every Linux command at once, divide learning into small topics. A beginner can use this sequence: **Week 1: Linux environment and commands** Learn how to inspect the operating system, navigate directories, read files and understand users and groups. **Week 2: Services and logs** Study systemd, service states, journalctl and application log locations. **Week 3: Storage and permissions** Practice filesystem checks, ownership, permissions and inode usage. **Week 4: Networking and troubleshooting** Study IP addresses, routing, DNS, ports and HTTP checks. After each topic, create a small practical exercise. Write down the commands, expected output and common errors. A structured [computer science](https://edmyra.com/) learning pathway can also help learners connect Linux administration with broader technical subjects. The important point is to use educational resources to strengthen understanding rather than replace practical experimentation. The wider subject of [skill learning](https://edmyra.com/why-skill-learning-is-essential-in-todays-world/) is useful here: technical concepts become more valuable when learners apply them to real tasks and review their results. ## 14\. Document Every Investigation A troubleshooting notebook can become one of the most useful tools for a Linux learner. For every problem, record: - Date and system environment. - Original symptom. - Commands executed. - Important command output. - Possible causes. - Changes made. - Final result. - Lessons learned. Do not copy large amounts of terminal output without explaining why it matters. For example, instead of writing only: "Ran df -h." Write: "Checked filesystem usage because the application could not create a report. The affected partition was at full capacity. Further investigation identified unusually large temporary files." This kind of explanation demonstrates understanding. Over time, the notebook becomes a reference for recurring problems and a record of practical experience. ## 15\. Use Linux Projects to Demonstrate Your Skills A learner can turn practical exercises into small technical projects. Examples include: - A script that records disk usage. - A report showing active services. - A Linux permission demonstration. - A network connectivity checklist. - A system log investigation. - A documented virtual-machine setup. Each project should explain the problem, the tools used and the result. Avoid presenting a project as production-ready unless it has been tested in an appropriate environment. State which distribution and version were used, and mention any limitations. Learners exploring [career courses](https://edmyra.com/5-online-courses-for-career-growth-in-2026/) can also use practical projects to connect technical learning with broader career development. A project is most useful when it clearly shows what the learner understands and can explain. ## Conclusion Linux troubleshooting becomes easier when it follows a clear diagnostic process. Begin by recording the symptom, identifying the environment and collecting evidence. Check system resources, services, logs, storage, permissions and networking in a logical order. Avoid random changes and broad permission modifications. Test one possible cause at a time, verify the result and document the investigation. The best way to become confident with Linux is to practice on a safe system, reproduce common problems and learn how to explain the solution. A person who understands why a command is useful is better prepared than someone who only remembers the command itself. With regular laboratory exercises and careful documentation, Linux troubleshooting can become a practical and valuable technical skill.