nginx service 显示 failed 但日志无错，主因是 systemd 的 Type 与 nginx 启动方式不匹配；需检查 Type=forking 和 PIDFile 配置是否正确，并执行 systemctl daemon-reload。
service 状态显示 failed 但日志没报错
systemctl status nginx 显示 failed，可 journalctl -u nginx 却找不到明显错误——这通常不是服务真挂了，而是 systemd 认为它“没按预期启动成功”。常见原因是服务类型（Type=）和实际行为不匹配。
-
Type=simple（默认）：systemd 启动主进程后立刻认为服务就绪；但若 nginx 实际是 fork 出子进程后父进程退出，systemd 就会误判为崩溃 -
Type=forking：适合真正 daemonize 的服务，需配合PIDFile=指向真实 pid 文件；漏配或路径错会导致状态假失败 - 检查
/usr/lib/systemd/system/nginx.service或/etc/systemd/system/nginx.service中的Type和PIDFile是否与 nginx 配置中pid /run/nginx.pid一致 - 改完记得
systemctl daemon-reload，否则 reload 不生效
journalctl 查不到刚发生的错误
执行 journalctl -u sshd --since "2 minutes ago" 返回空，不代表没出错——journal 默认只保留内存缓冲区 + 最近磁盘日志，重启后旧日志可能已轮转或未持久化。
- 确认日志是否启用持久存储：
ls /var/log/journal/；为空说明日志只存内存，重启即丢 - 启用持久化：
mkdir -p /var/log/journal，再systemctl restart systemd-journald - 查上一轮启动的日志用
journalctl -b -1，不是-b 0（后者是当前轮） - 某些发行版（如 CentOS 7）默认不开启 journald 持久化，
/etc/systemd/journald.conf中Storage=volatile就是罪魁
df 显示磁盘 100% 但 du 总和远小于此
这是典型的“被删除但进程仍占句柄”现象。文件被 rm 掉，但某个进程还在写它，空间不会释放，df 看得见，du 找不到。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 定位元凶：
lsof +L1列出所有已删除但仍被打开的文件；或lsof -n | grep deleted - 常见场景：
/var/log/journal/日志膨胀、/tmp下长期运行任务生成的临时文件、Java 应用未关闭的 log4j 日志流 - 释放空间不一定要杀进程：对 journal 可
journalctl --vacuum-size=200M；对普通文件，重启对应进程最稳妥 - 注意：
lsof在容器内可能看不到宿主机进程，得在宿主机上跑
SSH 登录卡在 password 提示前超过 10 秒
这不是网络延迟，是 sshd 在做反向 DNS 查询或 GSSAPI 认证，而你的 DNS 配置或 Kerberos 环境不工作。
- 验证方式：
ssh -vvv user@localhost，看到debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password后卡住，基本就是 GSSAPI 或 DNS 问题 - 临时绕过：
ssh -o GSSAPIAuthentication=no -o UseDNS=no user@host - 永久修复：编辑
/etc/ssh/sshd_config，设UseDNS no和GSSAPIAuthentication no，然后systemctl restart sshd - 别漏掉：如果服务器 /etc/hosts 里没把本机 hostname 解析到 127.0.0.1，
UseDNS no也救不了——sshd 内部仍会尝试解析自己
最常被忽略的是 journal 持久化和 /etc/hosts 的本地解析，这两处一错，很多“查不到日志”“SSH 卡顿”的问题就永远在原地打转。
