Linux 服务重启后找不到 PATH 怎么办：EnvironmentFile、登录 Shell 和启动日志排查

手工执行 /opt/order-worker/bin/worker 一切正常，改成 服务管理命令 restart order-worker 后却报“找不到命令”或读不到配置，这类问题在 Linux 服务器上很常见。关键差异是：服务管理器 不会加载你的登录 Shell 配置，服务拿到的是一套更小、更明确的环境。把环境来源、绝对路径和启动日志对上，通常几分钟就能定位。

这类问题不需要漫无目的调试配置，优先用 EnvironmentFile 显式声明服务需要的环境变量，避开登录Shell的隐式加载逻辑，再用 服务管理命令 show 核对服务实际拿到的PATH，结合journalctl启动日志排查，就能快速定位解决。

同一个二进制，为什么手工启动和 服务管理器 启动结果不同

这次故障发生在一台运行订单同步任务的 Ubuntu 主机上。值班同事 SSH 登录后执行：

cd /opt/order-worker
./bin/worker --config ./conf/worker.yaml

任务能连接 Redis；重启服务后，日志却出现 lookup redis: no such host 和“配置文件不存在”。乍看像网络或文件损坏，实际上两个启动入口至少有四个差异：

这里先别急着改 DNS。先确认服务进程到底拿到了什么环境。

先看 服务管理器 实际拿到的环境，而不是猜 PATH

查看 unit 的完整配置和 服务管理器 解析后的属性：

服务管理命令 cat order-worker
服务管理命令 show order-worker \
  -p User -p Group -p WorkingDirectory -p Environment \
  -p EnvironmentFiles -p FragmentPath

重点看 EnvironmentFiles 是否显示为已读取，WorkingDirectory 是否指向发布目录，以及 Environment 中是否真的存在 PATH= 和 WORKER_CONFIG=。如果属性里没有变量，应用日志里的“配置不存在”就不是应用层解析失败，而是注入环节没有生效。

还可以让 Shell 和 服务管理器 使用同一组命令做对照：

env | sort > /tmp/login-env.txt
服务管理命令 show-environment | sort
diff -u /tmp/login-env.txt 
对照时不必追求两边完全一致，服务只应拿到它真正需要的变量。
把 unit 文件收敛成可检查的启动契约
一个可维护的 unit 不依赖登录用户的 Shell 配置，而是把运行用户、工作目录、变量文件和绝对路径写清楚：
[Service]
Type=simple
User=order
Group=order
WorkingDirectory=/opt/order-worker
EnvironmentFile=-/etc/order-worker/worker.env
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/order-worker/bin"
Environment="WORKER_CONFIG=/etc/order-worker/worker.yaml"
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal
启动命令=/opt/order-worker/bin/worker --config ${WORKER_CONFIG}
EnvironmentFile=-... 前面的短横线表示文件不存在时不阻止启动。生产环境是否允许这样做要看配置性质：如果没有变量就不该启动，去掉短横线更安全，让错误尽早暴露。
配置文件建议放在 /etc/order-worker/，并限制为服务用户可读。变量文件使用简单的 KEY=value 形式，不要把 Shell 命令或依赖交互式登录的写法塞进去。
修改后先验证解析结果，再重启进程
编辑 unit 或变量文件后，先让 服务管理器 重新读取文件，再检查配置是否能被解析：
sudo 服务管理命令 daemon-reload
unit-analyze verify /etc/worker/service/order-worker.service
sudo 服务管理命令 restart order-worker
sudo 服务管理命令 status order-worker --no-pager
unit-analyze verify 只检查 unit 语法和引用关系，不会替你确认 Redis 可达或业务配置正确，所以它通过后仍要看服务日志。
journalctl -u order-worker -n 80 --no-pager
journalctl -u order-worker -f
如果看到 Failed at step CHDIR，优先检查 WorkingDirectory 是否存在以及 order 用户是否有搜索权限；如果是 Failed to locate program，检查启动路径和文件权限；如果程序已启动但读取配置失败，再看变量文件内容和应用自己的配置解析日志。
上线结果要看进程身份和重启后的真实状态
服务显示 active 不代表业务已经恢复。至少核对下面几项：

• 服务管理命令 is-active order-worker 返回 active，且没有短时间反复重启。
• ps -o user,group,pid,cmd -C worker 显示进程运行在预期的 order 用户下。
• 日志中出现配置加载、Redis 连接和首个任务完成的记录，而不是只有“Started”一行。
• 发布目录、/etc/order-worker/worker.yaml 和变量文件的权限符合最小权限原则。

如果服务依赖网络、挂载盘或远端 DNS，After=network-online.target 只表达启动顺序，不等于外部依赖一定可用。应用本身仍应有连接超时、重试和可读的失败日志。

常见问题：PATH 和 EnvironmentFile 还有哪些坑

把变量写进 .bashrc，服务管理器 会自动读取吗？

不会。服务通常不经过交互式登录 Shell；需要的变量应写进 unit 的 Environment 或 EnvironmentFile。

EnvironmentFile 里的值可以写成 export KEY=value 吗？

不建议依赖这种 Shell 语法。保持为简单的 KEY=value，并用 服务管理命令 show 检查解析后的结果。

改了 EnvironmentFile 为什么重启后仍是旧值？

变量文件内容通常会在服务启动时重新读取。若改的是 unit 文件，还需要执行 服务管理命令 daemon-reload；随后重启并查看 服务管理命令 show order-worker。

WorkingDirectory 不写会怎样？

进程可能从根目录或由管理器决定的目录启动，所有相对路径都会变得不可靠。配置、日志和数据文件尽量使用绝对路径。

把 服务管理器 启动环境当成部署契约

这类故障真正要修的不是某个 PATH 值，而是“服务依赖什么”没有被写下来。unit 文件明确运行身份、目录、变量来源和绝对启动路径，配合 unit-analyze verify、服务管理命令 show、journalctl -u 三组检查，重启后的行为才可复现。以后换机器或换发布目录时，按同一份契约核对，排查成本会比反复登录服务器试命令低得多。