服务器 CPU 100%，罪魁是个名字很奇怪的进程：一次挖矿木马应急响应
top 里一个名字怪异的进程吃满 CPU，杀了又活。本文从防御视角复盘一次挖矿木马应急：定位进程、/proc/PID/exe、外连矿池、cron 与 authorized_keys 持久化、日志溯源，以及清理与加固清单。
服务器与 Linux 排查
磁盘、内存、负载、句柄、网络连接、安全入侵——机器层面的问题。
Java 进程“人间蒸发”：没有 hs_err、没有 OOM 异常，凶手是 Linux 的 OOM Killer
服务凌晨无声消失，没有 hs_err 文件也没有 OutOfMemoryError。dmesg 里一行 Out of memory: Killed process 揭开真相：JVM 堆加堆外内存把机器吃光，被内核枪毙。附排查命令、oom_score 原理和堆参数预留算法。
load average 飙到 60，CPU 却在摸鱼：一场由 D 状态进程引发的“假繁忙”
监控里 load 飙到几十，top 里 CPU 却几乎空闲。原来 Linux 的 load 也统计 D 状态进程。用 vmstat、iostat -x、pidstat -d、iotop 和 ps 找出是磁盘慢还是 NFS 卡死，并讲清 await 与 %util 怎么读。
Too many open files：一个没关的 HttpClient，攒出了三万个 CLOSE_WAIT
接口突然大面积报 Too many open files。先分清 ulimit、limits.conf、systemd LimitNOFILE 与容器的差异，再用 lsof、ss 统计连接状态，定位到 CLOSE_WAIT 堆积，根因是 HttpClient 响应没关闭导致连接泄漏。
df 说磁盘 100%，du 说只用了一半：被 rm 了却还“活着”的日志文件
磁盘告警 100%，du 加起来却只有一半。原来是日志被 rm 了，Java 进程还握着文件句柄。用 lsof +L1 找到它，/proc/PID/fd 截断止血，再顺带讲 inode 耗尽、大文件定位和 logrotate copytruncate。
手敲能跑，放进 cron 就“装死”：定时任务没执行的八种死法
备份脚本手敲一切正常，放进 crontab 却悄无声息地不执行。逐条排查 cron 服务与日志、PATH 环境变量、百分号转义、时区、权限、输出重定向、flock 防重叠、时间漂移，并对比 XXL-JOB。