Master Linux Troubleshooting: 6 Common Issues and How to Fix Them

General Linux Troubleshooting Workflow

Pay close attention to error messages; they often pinpoint the root cause.

Examine relevant log files in /var/log and application‑specific logs to gather more context.

Analyze the combined information from error messages and logs to locate the exact problem.

Apply the appropriate fix once the cause is identified.

Problem 1: Filesystem corruption prevents system boot

The boot process reports:

/dev/sda6 contains a file system with errors, check forced
An error occurred during the file system check

This usually occurs after an unexpected power loss, leaving the filesystem inconsistent. The remedy is to force a repair with fsck:

# umount /dev/sda6
# fsck.ext3 -y /dev/sda6

Problem 2: "Argument list too long" error

The error appears when a command receives more arguments than the kernel permits. Example:

# crontab -e
(no space left on device)

Root cause: the /var partition is full, often due to large mail queues. Steps to resolve:

Check disk usage: # df -h Identify large directories: # du -sh * (e.g., /var/spool/clientmqueue consumes ~90% of /var)

Remove or truncate files. Common methods:

Delete by pattern: # rm [a-n]* -rf and # rm [o-z]* -rf Use find: # find /var/spool/clientmqueue -type f -exec rm -f {} \; Shell script loop:

#/bin/bash
RM_DIR="/var/spool/clientmqueue"
cd $RM_DIR
for i in $(ls); do rm -f $i; done

Recompile the kernel with a larger MAX_ARG_PAGES value (e.g., change from 32 to 64 or 128 in include/linux/binfmts.h and rebuild).

Problem 3: Inode exhaustion causing application failure

An Oracle listener fails to start with "No space left on device" despite ample disk space. The issue is inode depletion.

Check inode usage: # df -i Inspect inode count for a specific partition: # dumpe2fs -h /dev/sda3 | grep 'Inode count' List files with their inode numbers using ls -i. To free inodes, delete unnecessary files, e.g.:

# find /var/spool/clientmqueue/ -name "*" -exec rm -rf {} \;

Problem 4: Deleted file does not free space

After removing a large /tmp/access_log (≈66 GB), df still shows the root partition full.

Reason: a running process (typically httpd) still holds the file descriptor, so the inode remains in use.

Identify such deleted‑but‑open files: # lsof | grep delete Solution options:

Restart or stop the holding process (e.g., # /usr/local/apache2/bin/apachectl stop).

Truncate the file without deleting it: # echo "" > /tmp/access_log.

Problem 5: "Too many open files" error

A Java web application reports java.io.IOException: Too many open files. The system limit is 65535, but the process still hits the ceiling.

Check the limit for the user running Tomcat: # ulimit -n Ensure the limit is applied in the appropriate places:

In the user’s shell profile ( .bashrc or .bash_profile).

In Tomcat’s startup.sh script (e.g., ulimit -n 65535).

In /etc/security/limits.conf:

www soft nofile 65535
www hard nofile 65535

If the limit was added after Tomcat started, a simple restart of Tomcat applies the new limit.

Problem 6: Read‑only filesystem error

The kernel may remount a filesystem as read‑only when it detects severe inconsistencies or hardware failures.

Typical recovery steps:

Unmount the affected partition (if possible): # umount /www/data. If the device is busy, identify the holding processes:

# fuser -m /dev/sdb1
# ps -ef | grep 8800

Stop the offending service (e.g., Apache) and retry unmount.

Run a filesystem check: # fsck -V -a /dev/sdb1 Remount the filesystem:

# mount /dev/sdb1 /www/data