Linux problems are far easier to fix once you can name the symptom precisely. “The system is broken” gives you little to work with; “Wi-Fi is connected, but DNS lookups fail” points to a specific area. Before changing anything, record the command you ran, the full error message, when the issue started, and any recent changes such as package updates, configuration edits, new hardware, or permission changes.
On an important system, resist the urge to paste random fixes from forums. A command that solves a problem on one distribution can overwrite configuration, remove necessary packages, or complicate recovery on another. Check the current state, make small changes you can reverse, and confirm the result after each step.
Use a repeatable troubleshooting process
Most Linux problems benefit from the same basic process. It limits guesswork and leaves you with useful notes if you need help from a colleague, instructor, or distribution support community.
- Define the failure precisely. Establish what is failing, what still works, and whether the problem affects one user, one application, or the entire machine.
- Reproduce it safely. Repeat only the harmless action that triggers the issue. Note whether it happens every time or only intermittently.
- Check recent changes. Updates, edits under
/etc, a nearly full disk, and changed permissions are common causes. - Read relevant logs and status output. Services often explain why they failed, but the explanation may appear in the journal rather than in a desktop notification.
- Test one likely cause at a time. Do not change the network manager, firewall rules, DNS settings, and router configuration all at once.
- Document the fix. Save the commands you used, the files you edited, and why the change worked. Those notes can save time the next time the problem appears.
Gather basic system information first
A few read-only commands provide a dependable starting point. They are also useful when requesting authorized support because they describe the system without exposing passwords or private keys.
uname -a
cat /etc/os-release
uptime
whoami
pwd
lsblk
df -hcat /etc/os-release identifies the distribution and version. uname -a shows kernel information, while uptime reports how long the system has been running and includes load averages. lsblk lists storage devices, and df -h shows mounted filesystem usage in readable units.
Take care when posting command output publicly. Remove usernames, hostnames, internal IP addresses, mount paths that reveal personal data, and any tokens that may appear in application logs.
When a command says permission denied
Permission errors usually come down to one of four causes: your user lacks access, ownership is incorrect, the filesystem is mounted read-only, or the program requires a capability unavailable to ordinary users. Running everything as root is rarely the right answer.
Check identity, ownership, and mode bits
id
ls -ld /path/to/directory
ls -l /path/to/file
namei -l /path/to/fileid lists your user and group memberships. Directory permissions matter just as much as file permissions: to reach a file, a user needs execute permission on every directory in its path. namei -l is useful here because it shows permissions for each part of that path.
If you own a file and only need a reasonable permission change, make the narrowest change that solves the problem. For example, chmod u+x script.sh adds execute permission for the owner only. Avoid chmod -R 777. It grants overly broad access, can undermine intended controls, and seldom addresses the real cause.
When a file belongs to the wrong account, verify the intended owner before using chown. System files and application directories may need a particular service account rather than your login account. If a filesystem is read-only, inspect its mount state with mount | grep ' /target/path ' and review kernel messages before trying repairs.
When software will not install or update
Package failures often stem from unavailable repositories, interrupted package operations, low storage, dependency conflicts, or an unsupported distribution release. Identify the package manager first, then read the complete error output.
| Symptom | Useful first check | Common safe response |
|---|---|---|
| “No space left on device” | df -h and df -i |
Free space or inodes on the affected filesystem before trying again. |
| Repository cannot be reached | Network connectivity and configured repository URLs | Check DNS, system time, and whether the repository matches your release. |
| Package database locked | Running package processes | Allow legitimate updates to finish. Do not remove lock files while a package manager is active. |
| Dependency conflict | Exact package names and versions | Review held packages, third-party packages, or packages from mixed releases before forcing changes. |
On Debian- and Ubuntu-based systems, apt update refreshes package metadata. On Fedora systems, dnf check can help identify dependency problems. Run administrative package commands only against trusted repositories, and avoid scripts that instruct you to disable signature verification. Package signatures and secure repository settings help protect you from tampered software.
When a service fails to start
A service may fail because its configuration is invalid, a required port is already occupied, a dependency has not started, or the process cannot access a needed file. On systems that use systemd, start with the service status and its journal entries:
systemctl status service-name
journalctl -u service-name -b
systemctl cat service-nameReplace service-name with the actual unit, such as ssh, nginx, or an application service. The -b option limits output to the current boot, so older failures do not hide the present one. Look for lines marked “error,” “failed,” “permission denied,” “address already in use,” or references to a configuration file and line number.
Before restarting a production service, validate its configuration if the software offers a test mode. Web servers, database servers, and many language runtimes provide syntax checks. A restart may interrupt users; a configuration test usually will not.
When networking works only partly
Networking is easier to diagnose when you separate interface status, IP routing, DNS resolution, and application access. A browser error alone cannot tell you which layer is at fault.
- Check network interfaces and assigned addresses with
ip addr. - Review the default route with
ip route. - Test local gateway reachability only on networks you own or are authorized to administer.
- Test name resolution with
getent hosts example.com. - Inspect configured resolvers with
resolvectl statuswhere systemd-resolved is in use.
If an IP address responds but the hostname does not, DNS is the likely issue rather than Wi-Fi or Ethernet. If names resolve but one application still cannot connect, check that application's proxy settings, local firewall policy, and service endpoint. Keep testing limited to your own systems, lab environments, or networks where you have explicit authorization.
When the desktop freezes or the system feels slow
A frozen window does not always mean the operating system has frozen. On many desktop distributions, try switching to a text console with Ctrl+Alt+F3, then log in and inspect resource usage. Return to the graphical session with the appropriate function key, often Ctrl+Alt+F1 or Ctrl+Alt+F2, depending on the distribution.
top
free -h
ps aux --sort=-%mem | head
ps aux --sort=-%cpu | head
dmesg -T | tail -n 50free -h helps distinguish genuinely low available memory from normal Linux filesystem cache behavior. The ps output may reveal a browser tab, compiler, virtual machine, or runaway program using most of the system's resources. Kernel messages from dmesg -T can reveal storage errors, driver resets, or out-of-memory events.
Do not kill a process immediately unless you have to. First identify the process and its parent with ps -fp PID. Close it normally where possible, then use kill PID to request a graceful stop. kill -9 PID prevents cleanup, so reserve it for a process that does not respond to normal termination.
Boot failures and recovery choices
If Linux stops during boot, capture the exact message or photograph it with another device. Messages such as “failed to mount,” “dependency failed,” or “emergency mode” point to a particular subsystem. Rebooting repeatedly without recording the error can make an intermittent hardware or filesystem problem harder to trace.
When the system reaches an emergency shell, do not edit unfamiliar boot parameters or run destructive filesystem repair commands blindly. Identify the affected mount with findmnt, inspect journalctl -b, and check whether a recently edited /etc/fstab entry has an incorrect UUID, device name, or mount option. A typo in /etc/fstab can prevent normal boot because filesystems are mounted before many services start.
If you boot from a trusted live USB for recovery, mount disks carefully and back up important files before making repairs. Confirm device names with lsblk -f. Names such as /dev/sda can change between boots, while UUIDs identify filesystems more reliably. For encrypted disks, follow your distribution's documented recovery process and never post recovery keys or passphrases in a support request.
Logs that answer common questions
On a systemd-based distribution, journalctl -p err -b filters the current boot for error-priority messages. To inspect a particular period, use an explicit time range:
journalctl --since "2025-01-15 09:00" --until "2025-01-15 10:00"
journalctl -k -bThe second command shows kernel messages from the current boot. Match timestamps to the time the failure occurred. If a USB drive disappears at 14:22, inspect messages around 14:22 instead of reading thousands of unrelated lines. That focused check can show whether the problem began with hardware detection, a driver, a mount operation, or the application using the device.
