Stop Using ‘ll’: 10 Linux Commands That Can Boost Your Efficiency by 50%

1. htop / btop – Better Process Monitoring

Problem background : The default top shows a flat view with limited sorting and no mouse support, making it hard to quickly identify the offending process.

Typical scenario : High CPU load, memory pressure, or I/O spikes where you need to identify the top‑resource consumer.

Command :

# Install
sudo yum install htop -y   # CentOS/RHEL
sudo apt install htop -y   # Ubuntu/Debian

# Launch
htop

# Show processes of a specific user
htop -u www-data

# Change refresh interval (default 3 s)
htop -d 10

# Show specific PID tree
htop -p 1234,5678

Interactive shortcuts (press after entering htop): ↑/↓ – select process →/← – change column P – sort by CPU M – sort by memory t – toggle process tree k – kill selected process (confirm first) l – show open files (lsof‑style) s – strace the process (use cautiously in production)

Risk reminder :

Never kill an unknown process in production without confirming its purpose.

Running strace can heavily impact performance; limit to test environments.

CPU % shown is the sum of all cores; to see per‑core usage adjust in the setup.

Thread count can inflate CPU usage; hide threads with H if needed.

Verification :

# Verify installation
htop --version

# Confirm a process is listed
ps aux | grep nginx | grep -v grep

2. glances – One‑Screen System Overview

Problem background : htop focuses on processes, but sometimes you need a quick snapshot of CPU, memory, disk I/O, network, and services in a single view.

Typical scenario : Evaluating a new server, checking health before a deployment, or monitoring multiple hosts remotely.

Command :

# Install
sudo yum install glances -y   # CentOS/RHEL
sudo apt install glances -y   # Ubuntu/Debian

# Run interactive view (default refresh 2 s)
glances

# Set refresh interval to 1 s
glances -t 1

# Show per‑CPU stats
glances --per-cpu

# Export JSON for automation
glances -o JSON

# Remote server mode (server)
glances -s

# Connect from client
glances -c <server_ip>

Key metrics explained : CPU: user, system, iowait, idle percentages. MEM: total, used, available, cached. SWAP: usage indicates memory pressure. DISK I/O: read/write rates; high values point to storage bottlenecks. NETWORK: inbound/outbound traffic per interface.

Risk reminder :

When run inside a container, network stats may be incomplete.

High refresh rates ( -t 1) increase CPU load; keep default on low‑spec machines.

Remote mode has no authentication by default; restrict to internal network or use SSH tunnels.

Verification :

# Verify version
glances --version

# Test JSON output
glances -o JSON | head -n 5

# Check remote connectivity
glances -c 127.0.0.1

3. ncdu – Interactive Disk‑Usage Explorer

Problem background : du -sh * is slow and unsortable; locating large directories on a busy server can take minutes.

Typical scenario : Disk usage >90 % on /, need to find the culprit files quickly.

Command :

# Install
sudo yum install ncdu -y   # CentOS/RHEL
sudo apt install ncdu -y   # Ubuntu/Debian

# Scan current directory
ncdu

# Scan a specific path, exclude virtual filesystems
ncdu /var --exclude /proc --exclude /sys

Interactive shortcuts : ↑/↓ – select directory → or Enter – enter selected directory ← or l – go back d – delete selected file/directory (confirmation required) s – sort by size (default) n – sort by name e – toggle hidden files r – rescan current directory q – quit

Risk reminder :

Scanning large filesystems generates heavy I/O; run during off‑peak hours.

Deletion is permanent; double‑check with lsof +L1 that the file isn’t still open.

Network filesystems (NFS, CIFS) may be slow; consider mounting locally for analysis.

Verification :

# Verify installation
ncdu --version

# Quick size check
du -sh /var/log

4. journalctl – Systemd Log Query Engine

Problem background : Traditional tail -f or grep on log files is inefficient for multi‑host or time‑range searches.

Typical scenario : Debugging a failing service, investigating a crash, or extracting error‑level entries across reboots.

Command :

# Show all logs (paged)
journalctl

# Follow live logs (like tail -f)
journalctl -f

# Show logs since a specific time
journalctl --since "2026-05-15 10:00:00"

# Filter by service
journalctl -u nginx

# Show only error level
journalctl -p err

# Show logs from the current boot only
journalctl -b

# Export JSON for external tools
journalctl -o json > nginx.json

# Vacuum old logs, keep last 7 days
journalctl --vacuum-time=7d

Risk reminder :

By default Storage=auto may keep logs only in memory; enable Storage=persistent for long‑term retention.

Vacuum commands permanently delete old logs; back them up first if needed.

When used in scripts, add --no-pager to avoid hanging.

Verification :

# Verify service is logging
systemctl status systemd-journald

# Check storage mode
grep Storage /etc/systemd/journald.conf

# Show recent logs without pager
journalctl -n 20 --no-pager

5. ss – Fast Socket Statistics

Problem background : netstat -tunp is slow on high‑traffic servers because it traverses /proc/net for each lookup.

Typical scenario : Identifying which process holds a port, spotting many TIME_WAIT sockets, or detecting abnormal ESTABLISHED connections.

Command :

# List all TCP/UDP sockets with process info
ss -tunap

# Show listening ports only
ss -tlnp

# Filter by port 80
ss -tlnp | grep :80

# Show only ESTABLISHED connections
ss -tnp state established

# Count TIME_WAIT sockets
ss -s | grep timewait

# Show per‑process sockets
ss -p | grep nginx

Risk reminder :

Running ss -s on >100k connections may briefly block the kernel; use sparingly.

Port‑conflict detection works only for listening sockets; it won’t catch hidden bind‑fails. tcp_tw_reuse helps reuse TIME_WAIT for outbound connections but does not affect inbound listeners.

Verification :

# Verify version
ss --version

# Quick sanity check
ss -tlnp | wc -l

6. tree – Visual Directory Tree

Problem background : ls -R prints a flat list, making it hard to grasp nested project structures.

Typical scenario : Exploring a new codebase, locating configuration files, or generating a directory map for documentation.

Command :

# Basic tree of a directory
tree /etc/nginx

# Show hidden files
tree -a /data

# Show directories only
tree -d /opt

# Limit depth to 3 levels
tree -L 3 /var/log

# Exclude common noise directories
tree -I "node_modules|.git|__pycache__|target" /home/project

# Output with sizes
tree -h /var/log

# Export JSON (for scripts)
tree -J /etc/nginx > nginx.json

Risk reminder :

Scanning the whole filesystem ( tree /) is extremely I/O‑heavy; limit depth or target sub‑paths.

By default tree does not follow symlinks; use -L with caution to avoid recursive loops.

Verification :

# Verify installation
tree --version

# Quick test on a small directory
tree -L 2 /tmp

7. watch – Repeated Command Execution

Problem background : Manually re‑running a command to watch a changing metric is tedious and error‑prone.

Typical scenario : Waiting for a service to start, monitoring disk space after cleanup, or watching connection counts.

Command :

# Basic usage (every 2 s)
watch ss -s

# Faster interval (1 s)
watch -n 1 ss -s

# Highlight changes (default)
watch -d ss -s

# Run multiple commands
watch -n 2 'echo "=== CPU ===" && uptime && echo "=== MEM ===" && free -h'

# Monitor a log tail
watch -n 1 'tail -n 5 /var/log/nginx/access.log'

# Track process count
watch -n 1 "ps aux | grep nginx | grep -v grep | wc -l"

# Monitor directory size
watch -n 5 'du -sh /var/log'

Risk reminder :

Avoid high‑cost commands (e.g., mysqldump) with short intervals; they will overlap and overload the system. watch does not store history; for long‑term trends use sar or a monitoring system.

Press Ctrl+C to stop; exiting watch does not terminate the underlying command.

Verification :

# Verify installation
which watch

# Simple test
watch -n 1 date

8. xz / zstd / pigz – Efficient Compression

Problem background : gzip is ubiquitous but slow for large logs; xz gives the best ratio but is very slow; zstd and pigz strike a balance.

Typical scenario : Archiving a 10 GB log directory before backup.

Command :

# gzip (default)
gzip -9 file.txt          # max compression, slow
gzip -c file.txt > file.txt.gz

# xz – high compression, multi‑threaded
xz -T0 -e -9 file.txt

# zstd – fast, good ratio
zstd -19 file.txt          # high compression
zstd -1 file.txt           # fastest

# pigz – parallel gzip (drop‑in replacement)
pigz -p 8 file.txt

# Tar + compression examples
# tar + zstd (recommended for speed)
time tar -I zstd -cf logs.tar.zst /var/log

# tar + pigz (gzip compatible, faster)
time tar --use-compress-program=pigz -cf logs.tar.gz /var/log

# tar + xz (best ratio, slow)
time tar -I xz -cf logs.tar.xz /var/log

Risk reminder :

Compression is CPU‑intensive; run with nice -n 19 on production hosts. zstd may not be available on very old systems; keep gzip as fallback.

By default zstd deletes the source file; use -k to keep it.

Do not use pigz unless the target system can decompress .gz files.

Verification :

# Verify tools
xz --version
zstd --version
pigz --version

# Test integrity
zstd -t file.txt.zst
xz -l file.txt.xz

9. mtr – Combined Ping & Traceroute

Problem background : ping shows latency, traceroute shows hops, but they are separate tools. mtr combines both, providing continuous loss and latency statistics per hop.

Typical scenario : Users report slow website access; you need to see where latency or loss occurs.

Command :

# Interactive view
mtr 8.8.8.8

# One‑shot report (script‑friendly)
mtr -r -c 10 8.8.8.8

# Show AS numbers
mtr -b 8.8.8.8

# Output JSON for monitoring
mtr -j 8.8.8.8

# Use TCP SYN (bypass ICMP filters)
mtr -T -P 80 8.8.8.8

# Change interval (default 1 s)
mtr -i 2 8.8.8.8

Output fields explained :

Host                     Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.168.1.1            0.0%    10    1.2   1.5   1.0   2.1  0.3
2. 10.0.0.1               0.0%    10    5.4   5.8   5.2   6.3  0.4
3. 72.14.215.85           0.0%    10   12.3  15.1  11.8  22.4  3.2
4. 108.170.252.1          10.0%   10   18.7  20.1  17.2  28.3  4.1
5. 142.250.169.14         0.0%    10   22.1  23.4  21.5  25.2  1.2
6. 8.8.8.8                0.0%    10   25.3  26.1  24.8  27.5  0.8

Risk reminder : mtr sends many ICMP/TCP packets; long‑running probes can trigger firewall alerts. Use -c to limit the number of cycles.

High loss on intermediate hops may be due to ICMP rate‑limiting, not actual packet loss.

When ICMP is blocked, switch to TCP mode ( -T).

Verification :

# Verify installation
mtr --version

# Basic connectivity test
mtr -r -c 5 8.8.8.8

10. jq – JSON Query and Transformation

Problem background : Modern ops tools output JSON (Docker, Kubernetes, Prometheus). Using grep or awk on JSON is fragile.

Typical scenario : Extracting pod names, filtering running containers, or summarizing metric values.

Command :

# Pretty‑print
cat file.json | jq '.'

# Extract a top‑level field
jq '.name' file.json

# Extract a nested field
jq '.metadata.name' pod.json

# List all items in an array
jq '.items[]' list.json

# Filter running pods (Kubernetes example)
jq '.items[] | select(.status.phase == "Running") | .metadata.name' pods.json

# Count running pods
jq '[.items[] | select(.status.phase == "Running")] | length' pods.json

# Kubernetes example – list deployments and replicas
kubectl get deployment -o json | jq '.items[] | {name: .metadata.name, replicas: .spec.replicas, available: .status.availableReplicas}'

# Prometheus query result extraction
curl -s "http://localhost:9090/api/v1/query?query=up" | jq -r '.data.result[] | {instance: .metric.instance, value: .value[1]}'

# Log file with JSON lines – extract errors
cat app.log | jq -r 'select(.level == "error") | .message'

Risk reminder : jq expects valid JSON; filter non‑JSON lines first (e.g., grep '{').

Never output passwords to stdout; use -r only for non‑sensitive fields.

Array index out of bounds returns null; combine with select(. != null) if needed.

Verification :

# Verify version
jq --version

# Simple test on a small JSON snippet
echo '{"a":1}' | jq '.'