What are the first things I check when a Linux server suddenly becomes slow or unresponsive?

Linux Troubleshooting
1

Hey everyone,

I’m running into some issues on my Linux server and could use some help troubleshooting.

I’d like to know:

What are the first things I check when a Linux server suddenly becomes slow, unresponsive, or drops connections?

How do you usually examine logs, CPU, RAM, and disk usage to track down the root cause (commands, tools, or common patterns)?

Are there any must‑have monitoring or diagnostic tools you rely on regularly?

Also, if you’ve had similar Linux server problems before, what was the real culprit in your case and how did you fix it?

Thanks in advance for your command‑line wisdom and debugging tips!

2

Great question, when a Linux server hangs up, there are a few quick checks that usually point you to the culprit.

First things to check

Basic responsiveness:

  • ping and ssh to see if it’s reachable at all.

  • If you can log in, check if simple commands like who or ls hang.

System load and resources:

  • uptime → shows load averages; if they’re way above your CPU count, the system is overloaded.

  • htop or top → see which processes are using CPU or RAM.

  • free -h → check overall memory and swap usage.

Disk space and I/O:

  • df -h → look for full partitions (especially / and /var).

  • iotop or iostat → see if disk I/O is spiking.

How to check logs

System logs:

  • journalctl -xe (for systemd systems).

  • /var/log/syslog or /var/log/messages.

  • /var/log/auth.log or /var/log/secure for SSH‑related issues.

Service‑specific logs:

  • Web server: /var/log/nginx/access.log, /var/log/nginx/error.log or Apache equivalents.

  • PHP: often /var/log/php* or in the web‑server logs.

  • Database: MySQL/MariaDB logs, usually under /var/log/mysql/ or via systemctl status mariadb.

Common culprits and quick fixes

  • Out of disk space: clean up old logs, backups, or temp files; du -sh /* | sort -h helps find space hogs.

  • Process runaway: kill or restart the offending process after checking logs.

  • Misconfigured firewall or SSH settings: verify ufw/iptables and /etc/ssh/sshd_config; test from another IP if needed.

  • Resource‑heavy cron job or script: check /var/log/syslog or journalctl around the time things went bad and review /etc/cron.d, /var/spool/cron, etc.

Helpful tools to keep installed

Monitoring: htop, iotop, nethogs, netstat/ss, lsof.

Troubleshooting: journalctl, dmesg, strace/ltrace for deeper debugging.

If you paste the exact problem (e.g., “server freezes at 2 AM daily”) along with snippets from uptime, top, and the relevant logs, people here can help you narrow it down to a specific service or cron job.