用途
linux-service-triage 用于诊断常见的 Linux 服务问题，手段包括查看日志、检查 systemd/PM2 进程状态、排查文件权限、验证 Nginx 反向代理配置，以及做 DNS 基础检查。当服务器应用出现异常时，可用它来定位原因并给出修复思路。
主要能力
- 基于日志与状态输出进行故障分类：配置错误、依赖缺失、权限拒绝、端口冲突、上游不可达、DNS 不匹配等。
- 检查 systemd 单元或 PM2 进程的运行状态与监听端口。
- 分析文件系统路径权限，给出安全的 chown/chmod 方案。
- 验证 Web 服务网络链路：应用监听 → Nginx 代理 → DNS 解析 →（如适用）TLS 检查。
- 输出分诊报告，包含症状、证据、最可能原因、最小修复步骤、验证方式与回滚方案。
使用方式
需要提供：服务类型（systemd 单元名或 PM2 进程名）、观察到的症状（错误信息、状态输出或日志）。可选提供：Nginx 配置片段、域名、预期上游端口、服务使用的文件系统路径。
默认行为是只读诊断，基于用户提供的输出进行分析，不假设可以执行命令。只有在用户明确请求且操作安全时，才给出确切的 shell 修复命令。
工作流程：确认范围与安全性 → 收集证据（状态输出与近期日志）→ 分类故障 → 提出最小修复与验证步骤 → 验证网络路径（如为 Web 服务）→ 提供重启/重载计划并确认健康检查。
若缺少日志/状态输出、操作需要未确认的特权访问、或涉及 TLS/证书管理但设置未知，应停止并向用户询问。
适用场景
- 服务启动失败，需要从日志定位原因并给出修复命令。
- 需要干净地重启应用并确认监听在正确端口。
- 修复文件夹权限，使服务能安全读写。
- 为某端口设置 Nginx 反向代理，并验证 DNS 与 TLS 是否正常。
- 为脚本创建 systemd 服务并使其在重启后仍能运行。
限制
不适用于内核调试或深度性能分析，也不用于利用系统或绕过访问控制。默认只读，避免破坏性变更，任何有风险的操作都需要用户明确确认。建议在重载前先执行 nginx -t，并用 ss 验证端口。