Linux systemd 服务环境变量的 drop-in 配置

给已经上线的 Linux 服务补一个环境变量时，我更倾向于先创建 drop-in，而不是直接打开发行版提供的原始 unit 文件。这样做的好处是边界清楚：原始服务定义继续由软件包管理，自己的部署参数集中在覆盖目录里，回滚时也只需要撤销这一层。

本文只处理 systemd 的 Environment、EnvironmentFile 和同名变量优先级。目标是让服务最终拿到一组可解释的环境变量，同时知道改完以后哪些动作会让配置真正进入进程。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/

少量固定值直接写进 drop-in 的 Environment=；变量较多或需要独立维护时使用 EnvironmentFile=。同名变量不要靠猜，按 unit 来源、文件加载顺序和显式清空规则逐项判断。

先确定要改的 unit 和配置边界

drop-in 不是给任意进程注入变量的 shell 配置，它只影响被指定 unit 启动出来的服务进程。先把服务名、原始定义位置和当前启动方式确认清楚，避免把命令行启动的进程误当成 systemd 服务。

# 读取服务状态，确认 unit 名称、加载状态和最近一次启动结果
systemctl status demo-api.service --no-pager

# 查看 systemd 实际合并后的配置，先关注 Environment 相关行
systemctl cat demo-api.service

# 展开最终属性，便于确认服务是否已经带有环境变量配置
systemctl show demo-api.service --property=Environment --no-pager

systemctl cat 适合看“配置来自哪些文件”，systemctl show 适合看 systemd 当前暴露出来的属性。两者关注点不同：前者帮助你选择改动位置，后者帮助你发现变量是否已经进入 unit 的解析结果。

全流程总览：把变量配置拆成四层

我在部署中会把这件事拆成四层：先识别 unit，再创建 drop-in，然后选择直接赋值或外置文件，最后重载并重启服务。每一层只解决一个问题，出现异常时也比较容易回退。

少量固定值：直接写入 drop-in

只需要设置端口、运行模式或一个功能开关时，直接在 drop-in 中写 Environment= 最直观。使用 systemctl edit 会创建服务专属的覆盖文件，不需要手动猜目录层级。

# 打开 demo-api.service 的 drop-in 编辑入口
sudo systemctl edit demo-api.service

# 保存后让 systemd 重新读取 unit 文件
sudo systemctl daemon-reload

# 重新创建服务进程，使新的环境变量进入进程环境
sudo systemctl restart demo-api.service

在编辑器中写入下面这段内容：

[Service]
# 固定值适合放在 drop-in，随着服务一起回滚
Environment="APP_MODE=production"
# 值中有空格时使用引号，避免被拆成多个参数
Environment="LOG_LEVEL=info"

这里的 [Service] 是 drop-in 需要覆盖的 unit 段。环境变量不等于 shell 变量展开：不要把 $HOME、$(command) 之类写法当作会被 shell 执行的表达式。服务启动时拿到的是 systemd 解析后的字面值。

变量较多：把 EnvironmentFile 放到独立文件

变量超过几行后，直接堆在 unit 片段里会影响阅读和变更审查。此时可以把非敏感的运行参数放到单独文件，再在 drop-in 中用 EnvironmentFile= 引入。

# 创建一个只给该服务使用的配置目录
sudo install -d -m 0755 /etc/demo-api

# 创建变量文件；文件内容应由部署流程写入并按环境管理
sudoedit /etc/demo-api/runtime.env

# 用 drop-in 引用变量文件
sudo systemctl edit demo-api.service

# /etc/demo-api/runtime.env
# 一行一个变量赋值，注释说明变量用途
APP_MODE=production
LOG_LEVEL=info
API_TIMEOUT_SECONDS=15

[Service]
# - 前缀表示文件不存在时不让 unit 因此失败；确认这是有意选择
EnvironmentFile=-/etc/demo-api/runtime.env

EnvironmentFile= 的路径是否必须存在，应根据服务的启动契约决定。若文件是部署必需品，省略 -，让缺文件成为明确的启动错误；若文件只是某些环境的可选覆盖，才考虑使用 -。不要为了“启动不报错”把所有配置文件都标成可选。

另外，环境文件不是通用的 shell 脚本。它适合存放简单的变量赋值和注释，不应把它当成可以执行命令、读取另一个脚本或保存密钥的万能入口。敏感值应使用专门的凭据管理方案，并控制文件权限。

同名变量的优先级：先看来源，再看清空

最容易出错的是同一个变量在多个地方出现。此时不要只看最后编辑的文件，而要按 systemd 对 unit 的合并结果判断：drop-in 可以补充或覆盖原始 unit 的同名设置，多个环境来源的顺序和显式清空操作会改变最终环境。

可以用下面的思路处理冲突：

1. 先列出原始 unit、已有 drop-in 和每个 EnvironmentFile 的来源。
2. 对同名变量记录它出现的先后顺序，不用文件名或目录名猜优先级。
3. 如果需要移除原始 unit 中已经设置的变量，使用空的 Environment= 赋值表达“清空这一项”，再写入新的值。
4. 重载 unit 后再查看合并结果，确认空值没有被误解成业务需要的空字符串。

[Service]
# 先清掉上层 unit 已有的 FEATURE_FLAG，再给出唯一的新值
Environment=FEATURE_FLAG
Environment="FEATURE_FLAG=enabled"

# 明确指定这个服务要读取的运行参数文件
EnvironmentFile=/etc/demo-api/runtime.env

“清空”与“设置为空字符串”是两个不同意图。前者用于移除环境项，后者是让进程看到一个值为空的变量。配置审查时最好把这两种情况分开写，避免下一个维护者只看到空值而无法理解目的。

推荐的发布流程：修改、重载、重启、回滚

配置文件已经写好后，我会固定按下面顺序操作。顺序本身就是排障线索：如果 daemon-reload 后 systemctl cat 仍看不到 drop-in，问题在 unit 文件位置或语法；如果合并结果正确但服务行为没变，通常是忘记重启或应用自己覆盖了变量。

# 重新读取 unit 文件，不会自动重启正在运行的进程
sudo systemctl daemon-reload

# 查看合并后的 unit 片段，确认 drop-in 已被加载
systemctl cat demo-api.service

# 查看 systemd 解析出的环境属性
systemctl show demo-api.service --property=Environment --no-pager

# 让新进程使用新的环境；旧进程不会因为 daemon-reload 自动改变
sudo systemctl restart demo-api.service

# 只看本次启动后的服务状态，便于发现启动失败
systemctl status demo-api.service --no-pager

如果需要回滚，优先删除或移走自己创建的 drop-in，然后再次执行 daemon-reload 和 restart。不要直接删除整个服务目录，也不要覆盖原始 unit 作为“临时修复”，那会让软件包升级和后续定位变得更复杂。

# 让 systemd 打开当前 drop-in，删除自定义内容后保存退出
sudo systemctl revert demo-api.service

# 回滚后重新读取 unit 定义
sudo systemctl daemon-reload

# 重启服务，使回滚后的环境进入新进程
sudo systemctl restart demo-api.service

常见误区和适用边界

• 直接改原始 unit：软件包升级可能覆盖改动；自己的配置应放进 drop-in。
• 只运行 daemon-reload：它只刷新 unit 定义，不会改变已经运行的进程环境。
• 把 EnvironmentFile 当 shell 脚本：变量文件应保持简单、可审计，不要依赖命令替换或脚本副作用。
• 把缺失文件全部设为可选：关键配置缺失时静默启动，往往会把问题推迟到业务请求阶段。
• 把空值当清空：清除变量和设置空字符串的语义不同，配置中要明确表达意图。
• 把环境变量当密钥库：服务环境可能被诊断接口、崩溃信息或进程检查暴露，敏感值要单独治理。

一张速查表

最后可以把判断压缩成一句话：systemd 服务环境变量的维护重点不是“在哪里写一行变量”，而是把来源、优先级和进程生效时机分开管理。固定值放 drop-in，成组变量放 EnvironmentFile；每次改动后先重载 unit，再让新进程启动，回滚时只撤销自己拥有的覆盖层。

相关问题

为什么 daemon-reload 后服务里的环境变量没变化？

因为 daemon-reload 只让 systemd 重新读取 unit，已经存在的服务进程不会被重新创建。需要在确认合并配置后重启服务。

EnvironmentFile 缺失时服务一定会失败吗？

取决于配置是否使用了可选文件前缀。关键文件不建议静默缺失；可选覆盖文件才适合明确使用可选语义。

环境变量能不能直接保存密码？

不建议把它当作长期密钥存储。环境变量的可见范围和泄露路径取决于服务、诊断方式和运行权限，敏感值应交给专门的凭据管理机制。