Linux 自动化部署失败的排错思路

根本原因是环境不一致：PATH、权限、glibc版本、/bin/sh指向（dash/bas）、SElinux上下文、临时目录挂载选项等差异导致脚本或服务行为异常，需逐项验证。

为什么脚本在测试机跑通，一上生产就挂？

根本原因往往是环境不一致，而不是脚本本身有 bug。Shell 脚本极度依赖运行时上下文，PATH、用户权限、glibc 版本、甚至 /bin/sh 指向的解释器（dash vs bash）都可能让同一份脚本行为迥异。

• 用 ls -l /bin/sh 确认默认 shell —— debian/ubuntu 默认是 dash，不支持 [[ ]] 或数组，而 centos 通常是 bash
• 在脚本开头强制指定解释器：#!/usr/bin/env bash，避免隐式依赖系统默认
• 别信“PATH 一样”，执行 echo $PATH 对比两台机器；更稳妥的是所有命令写绝对路径，比如用 /usr/bin/curl 而非 curl
• 检查 glibc 兼容性：ldd --version | head -n1，若生产环境版本更低，编译好的二进制或 java 程序会直接报 GLIBCXX not found

服务启动成功了，但 curl 不通？查这三处

自动化部署常卡在“看似成功，实则不可用”阶段。启动命令返回 0 不代表服务真在监听、可响应、能连数据库。

• 确认端口监听：ss -tlnp | grep :8080，不是 netstat（已逐步淘汰），且必须带 -p 看属主，避免被其他进程占坑
• 验证本地连通性：curl -v http://localhost:8080/health，别只看 systemctl is-active —— 它只管进程是否存活
• 检查依赖服务状态：比如 tomcat 依赖数据库，要单独验证 mysql -h 127.0.0.1 -u app -p appdb -e "select 1"，不能只等应用日志报错才行动

权限问题不是 chmod 777 就完事

盲目加权限反而掩盖真实问题，还引入安全风险。Linux 权限失败的核心，其实是“谁在操作、对什么路径、以什么上下文”三者不匹配。

• 确认服务运行用户：ps -eo user,comm | grep jenkins，然后检查该用户对 /var/lib/jenkins 是否有读写权，而非 root 用户有没有权
• SELinux 是静默杀手：ls -Z /var/log/jenkins 查上下文，若显示 unconfined_u:object_r:default_t:s0 就大概率不对，应为 system_u:object_r:jenkins_log_t:s0；修复用 restorecon -Rv /var/log/jenkins
• 临时目录权限易被忽略：/tmp 或 /var/tmp 若被 noexec 或 nosuid 挂载，Java 应用或 python 的 tempfile 会静默失败，用 mount | grep tmp 核查

日志里没报错，但部署就是卡住？开 debug 模式

很多工具（Jenkins、Cobbler、ansible）默认日志级别太低，关键信息被过滤掉。别靠猜，要让系统“开口说话”。

• Jenkins 启动慢？在 /etc/sysconfig/jenkins 加 JENKINS_JAVA_OPTIONS="-Djava.util.Logging.Level=FINEST"，再看 journalctl -u jenkins -f
• Cobbler 部署卡在 PXE？运行 cobbler sync --verbose，并检查 /var/log/tftp.log 和 /var/log/messages 中 TFTP 请求是否到达
• Ansible 执行无响应？加 -vvv 参数，它会输出每一步的远程命令、环境变量和 stdout/stderr，比看 playbook 更快定位卡点

最常被跳过的一步，是没确认目标机器是否真正“干净”——残留的旧进程、锁文件（/var/run/myapp.pid）、未清理的临时目录，会让新部署在无人察觉时反复失败。上线前花 30 秒执行 ps aux | grep myapp 和 ls -l /tmp/*myapp*，远比事后翻几小时日志省力。