A critical Linux process just died out of nowhere
Here’s 7-step debugging playbook:
๐ ๐ฆ๐๐ฒ๐ฝ ๐ญ: ๐ฉ๐ฒ๐ฟ๐ถ๐ณ๐ ๐๐ต๐ฒ ๐ผ๐ฏ๐๐ถ๐ผ๐๐
๐บ ps aux | grep process_name โ Is it actually dead?
๐บpgrep -fl process_name โ Double-check memory
๐บdmesg -T | tail -50 โ Look for segfaults or OOM kills
๐ ๐ฆ๐๐ฒ๐ฝ ๐ฎ: ๐๐๐ป๐ ๐๐ต๐ฟ๐ผ๐๐ด๐ต ๐๐๐๐๐ฒ๐บ ๐น๐ผ๐ด๐
๐บjournalctl -xe –no-pager -n 50 โ Recent errors before crash
๐บtail -f /var/log/syslog โ Live warnings and crash messages
๐ ๐ฆ๐๐ฒ๐ฝ ๐ฏ: ๐๐ต๐ฒ๐ฐ๐ธ ๐ฟ๐ฒ๐๐ผ๐๐ฟ๐ฐ๐ฒ ๐ฐ๐ผ๐ป๐๐๐บ๐ฝ๐๐ถ๐ผ๐ป
๐บtop -o %CPU โ High CPU usage patterns
๐บ top -o %MEM โ Memory limit breaches
๐บdmesg | grep -i “oom” โ OOM Killer activity
๐ ๐ฆ๐๐ฒ๐ฝ ๐ฐ: ๐๐ป๐๐ฒ๐๐๐ถ๐ด๐ฎ๐๐ฒ ๐๐๐ผ๐ฟ๐ฎ๐ด๐ฒ ๐ถ๐๐๐๐ฒ๐
๐บ df -h โ Disk space exhaustion
๐บ iostat -xm 1 โ I/O bottlenecks causing freezes
๐บ dmesg | grep -i “error” โ File system corruption
๐ ๐ฆ๐๐ฒ๐ฝ ๐ฑ: ๐๐ถ๐ป๐ฑ ๐ณ๐ถ๐น๐ฒ ๐น๐ผ๐ฐ๐ธ ๐ถ๐๐๐๐ฒ๐
๐บlsof -p <PID> โ Stuck on locked files
๐บlsof | grep -iE “deleted|locked” โ Lingering file problems
๐ ๐ฆ๐๐ฒ๐ฝ ๐ฒ: ๐ง๐ฟ๐ฎ๐ฐ๐ธ ๐ฒ๐
๐๐ฒ๐ฟ๐ป๐ฎ๐น ๐ธ๐ถ๐น๐น๐
๐บjournalctl -u process_name –no-pager -n 50 โ Manual terminations
๐บlastcomm | grep process_name โ Who sent the kill signal
๐ ๐ฆ๐๐ฒ๐ฝ ๐ณ: ๐ฅ๐ฒ๐ฎ๐น-๐๐ถ๐บ๐ฒ ๐ฑ๐ฒ๐ฏ๐๐ด๐ด๐ถ๐ป๐ด
๐บstrace -p <PID> โ Live syscall monitoring
๐บgdb -p <PID> โ Attach debugger for deep inspection
The key is following this systematically rather than randomly trying commands.
Whether you manage AWS workloads, Kubernetes clusters, or bare metal servers, this debugging flow works universally.
Source @livingdevops
