6 Common Linux Ops Issues and How to Diagnose & Fix Them

As a competent Linux operations engineer, you need a clear, systematic troubleshooting mindset to quickly locate and resolve issues.

Pay attention to error messages – they often point directly to the problem.

Check log files – both system logs (/var/log) and application logs provide deeper insight.

Analyze and locate the root cause – combine error messages, logs, and contextual information.

Resolve the issue – once the cause is identified, fixing becomes straightforward.

Below are six typical Linux operational problems and step‑by‑step solutions.

Problem 1: Filesystem corruption prevents boot

The error /dev/sda6 contains a file system with errors, check forced usually stems from an unexpected power loss that leaves the filesystem inconsistent.

Fix:

# umount /dev/sda6

# fsck.ext3 -y /dev/sda6

Problem 2: "Argument list too long" error

The issue appears when the /var partition is full, often due to large mail queue files.

Typical workflow:

# df -h

# du -sh /var/* | sort -nr | head -3

Solutions include removing files with patterns, using find, or recompiling the kernel to increase MAX_ARG_PAGES:

# find /var/spool/clientmqueue -type f -exec rm -f {} \;

Problem 3: Inode exhaustion causing Oracle listener failure

Even when disk space appears sufficient, running out of inodes prevents file creation.

Check inode usage:

# df -i

# dumpe2fs -h /dev/sda3 | grep 'Inode count'

Identify and delete offending files:

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

Problem 4: Deleted file does not free space

A large /tmp/access_log file was deleted, but space remained occupied because the Apache process still held the file descriptor.

Identify locked deleted files: # lsof | grep delete Release space by truncating the file:

# echo "" > /tmp/access_log

Problem 5: "Too many open files" in a Java web app

The error indicates the process has exhausted the allowed number of file descriptors.

Check limits: # ulimit -n Ensure the www user has proper limits in /etc/security/limits.conf and restart Tomcat after adjusting:

# cat /etc/security/limits.conf | grep www

www soft nofile 65535

www hard nofile 65535

After confirming the limits, a simple Tomcat restart resolves the issue.

Problem 6: Read‑only file system error

This occurs when the filesystem detects serious inconsistencies or hardware faults and remounts as read‑only.

Typical fix sequence:

# umount /www/data

# fuser -m /dev/sdb1

# /usr/local/apache2/bin/apachectl stop

# fsck -V -a /dev/sdb1

# mount /dev/sdb1 /www/data

After repairing, the filesystem returns to normal read‑write mode.