Ubuntu 22.04 升级 24.04 后 Linux 服务环境变量失效：旧 unit 的迁移与回滚

一台 Ubuntu 22.04 应用机升级到 24.04 后，Go 服务能被 服务管理器 正常拉起，却连不上新的 Redis 地址。手工在 shell 里启动完全正常，journalctl -u inventory-api 里却出现了“配置为空”的日志。这个现象通常不是 Go 配置解析逻辑突然出了问题，而是旧 unit 仍在读取已经不存在的环境文件，或者改完文件后只重启了服务，没有让 服务管理器 重新加载 unit。

升级范围：Ubuntu 24.04 改变了什么，哪些东西没有自动替你迁移

Ubuntu 22.04 内置的 服务管理器 主版本是 v249；24.04 内置的版本是 v255.4。版本变化本身不等于 unit 一定失效，但大版本升级会重新安装或替换部分包、清理系统里的失效路径，也可能让运维人员误以为“当前目录里的 service 文件”就是 服务管理器 正在使用的版本。

本例只迁移一件事：让名为 inventory-api.service 的 Go 服务稳定读取外部环境文件。应用二进制、端口和 Redis 客户端代码都保持不变，避免把操作系统升级、应用升级和配置改造混成一次不可回溯的改动。

先做一张变更表：旧 unit 的风险在哪里

旧写法为什么在升级后容易暴露问题

很多旧 unit 会把环境项直接写在服务文件里，或者引用部署目录下的相对路径。升级后，部署目录可能被系统重新创建，文件权限也可能被重置；更隐蔽的是，/etc/systemd/system 下的 drop-in 会覆盖发行包中的同名配置，读错文件比“文件不存在”更难排查。

[Unit]
Description=Inventory API
After=network-online.target

[Service]
User=inventory
WorkingDirectory=/srv/inventory
Environment=REDIS_ADDR=10.10.8.21:6379
EnvironmentFile=/srv/inventory/.env
Type=simple

[Install]
WantedBy=multi-user.target

这里藏着三个迁移风险：第一，/srv/inventory/.env 可能不再存在；第二，环境文件由部署用户维护，权限可能宽于密钥存储的安全要求；第三，unit 改过后，服务管理器 不会因为你保存了文件就自动重新读取它。这个时候先别直接下故障结论，先看 服务管理器 最终拼出的完整配置。

新写法：用固定配置目录承接迁移

先创建配置目录和环境文件。示例中的 Redis 地址、端口和服务令牌都是演示值，生产环境应通过已有的密钥分发流程写入。

sudo install -d -o root -g inventory -m 0750 /etc/inventory-api
sudo install -o root -g inventory -m 0640 /dev/null /etc/inventory-api/app.env
sudo sh -c 'cat > /etc/inventory-api/app.env' 

然后用 drop-in 覆盖环境来源。这样做的好处是发行包里的 unit 不需要直接改写，后续系统升级时更容易区分“系统提供的默认内容”和“本机的运维自定义策略”。

sudo install -d /etc/systemd/system/inventory-api.service.d
sudo sh -c 'cat > /etc/systemd/system/inventory-api.service.d/20-environment.conf' 

如果旧 unit 里的环境文件仍然存在，先用 systemctl cat inventory-api 看清楚它与 drop-in 的合并结果。必要时在 drop-in 中清空旧的环境文件项，再声明新的路径；不要凭感觉重复添加多个环境来源。

每一步都要核对：重载、重启、日志和端口

配置写好后，按下面顺序操作。重载 服务管理器 是让 服务管理器 重新读取所有 unit 配置；重启服务是让新启动的进程获得新的环境变量；两者完全不是同一个动作。

sudo systemctl daemon-reload
sudo systemctl restart inventory-api
sudo systemctl is-active inventory-api
sudo systemctl status inventory-api --no-pager
sudo journalctl -u inventory-api -n 40 --no-pager
ss -lntp | grep ':8080'

日志里应能看到应用自己输出的安全摘要，例如 config loaded: env=production redis=10.10.8.21:6379。不要把完整令牌打印到 journal 里；只打印环境名、地址和端口这类不敏感字段，足够判断来源是否正确。

回归检查：把“服务是 active”拆成三个可验证结果

• 配置层：systemctl show inventory-api -p EnvironmentFiles 能指向 /etc/inventory-api/app.env；不要把完整令牌值贴到运维工单里。
• 进程层：systemctl is-active inventory-api 返回 active，并且重启时间与本次迁移操作的时间一致。
• 业务层：本机请求服务的健康检查接口，确认返回 200；如果接口支持 Redis 探活，还要检查响应里的依赖连通状态。

curl -fsS http://127.0.0.1:8080/health
# {"status":"ok","redis":"ready"}

若只看第一项，服务可能是假活跃：进程虽然启动了，但配置为空后自动走了默认无效值。若只看健康接口，也可能漏掉 unit 来源错误，因为应用启动时已经把旧配置读进内存了。三层一起校验，才有资格结束本次迁移。

失败时怎么回滚：恢复旧路径，再按同一顺序验证

迁移前先保存两个副本：旧 unit 的导出结果和旧环境文件。回滚时把 drop-in 临时移开，恢复旧环境文件，再依次执行重载、重启、查日志的操作。不要直接删除整个 /etc/systemd/system 目录，那会把同机其他服务的本地自定义策略一起抹掉。

sudo mv /etc/systemd/system/inventory-api.service.d/20-environment.conf \
  /etc/systemd/system/inventory-api.service.d/20-environment.conf.disabled
sudo systemctl daemon-reload
sudo systemctl restart inventory-api
sudo journalctl -u inventory-api -n 40 --no-pager

如果旧路径已经不存在，回滚不能靠猜测。此时应先停止服务的自动重启，恢复备份的环境文件或从配置管理系统重新拉取对应版本，再启动服务。保留完整的失败日志，下一次只修一个变量来源，别把 unit、二进制和数据库连接同时换掉。

迁移清单：把一次排障变成可重复动作

1. 记录升级前的 systemd --version、systemctl cat inventory-api 和健康检查结果。
2. 确认 /etc/inventory-api/app.env 的属主、属组和权限，避免密钥被普通用户读取。
3. 用 drop-in 保存本机自定义差异，检查是否存在重复或过期的环境文件项。
4. 执行 daemon-reload、restart、status、journalctl、health 五项检查。
5. 预先演练禁用 drop-in 的回滚路径，并保留最近一次成功运行的日志。

相关问题

只修改 app.env 后需要 daemon-reload 吗？

如果只改环境文件内容，通常重启服务就能让新进程读取新值；如果修改了 unit 或 drop-in，则必须先执行 daemon-reload，再重启服务。

为什么 systemctl status 显示 active，接口仍然连不上 Redis？

active 只说明服务进程还在运行，不能证明它拿到了正确配置。继续核对 unit 合并结果、应用启动日志和实际健康检查结果即可找到问题。

环境文件可以放在应用目录里吗？

可以，但后续升级和发布时更容易被覆盖或误删。对系统服务，更建议把它放到 /etc/inventory-api，再用权限和配置管理工具控制访问范围。

小结

Ubuntu 22.04 升级到 24.04 时，真正需要迁移的往往不是某一行配置，而是“服务管理器 最终读取了哪份配置”这件事。固定环境文件路径、用 drop-in 保存本机差异，并用重载、日志、端口和健康接口完成闭环，能把一次看似玄学的启动异常变成可复查的标准变更流程。