Linux 服务怎样安全加载环境文件

Linux 服务需要读取一组运行参数时，推荐把环境文件放在服务专用目录，设为 root:appenv、权限 0640，再在单元的 [Service] 中使用 EnvironmentFile=。这样既不会把值塞进启动命令，也能把“文件能否被 systemd 读取”和“进程是否拿到变量”分开排查。

官方地址：https://github.com/systemd/systemd

EnvironmentFile 只写变量赋值，不是 shell 脚本

一个容易被忽略的边界是：systemd 读取的是环境变量赋值。把 export、命令替换或一串 shell 逻辑直接塞进文件，往往会得到和交互式终端不同的结果。先从最小格式开始：

# 每行是一个变量赋值，注释说明用途
APP_MODE=production
APP_PORT=8080
APP_NAME="order-api"
# 值中包含空格时使用引号，避免把空格误当作分隔
LOG_FORMAT="json compact"

变量名、等号和变量值要保持清楚。需要空格时使用引号；不要把 source config.sh、$(command) 或密码打印命令当成配置语法。引用变量的细节要结合 systemd 当前版本文档确认，不能把 Bash 的全部语法想当然地套过来。

在 [Service] 中固定路径和缺失文件策略

把文件放到 /etc/myapp/myapp.env，单元文件只保留服务需要的入口。路径前的短横线表示文件不存在时不让该项本身阻止启动；如果变量是服务启动必需品，就不要使用这个前缀，让错误尽早暴露。

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

[Service]
# 用专用身份运行，避免服务默认继承 root 权限
User=appuser
Group=appenv
# 配置文件缺失时让 systemd 报错，适合必需变量
EnvironmentFile=/etc/myapp/myapp.env
# 使用绝对路径，减少 PATH 环境差异
ExecStart=/usr/local/bin/order-api

[Install]
WantedBy=multi-user.target

如果文件只是可选覆盖项，可以写成 EnvironmentFile=-/etc/myapp/myapp.env。但“可选”应是业务决定，而不是为了让服务暂时启动而隐藏拼写错误。改动单元后执行：

# 让 systemd 重新读取单元文件，再重启进程加载新变量
sudo systemctl daemon-reload
sudo systemctl restart order-api.service
# 查看本次启动的状态和最近日志
sudo systemctl status order-api.service --no-pager
sudo journalctl -u order-api.service -n 50 --no-pager

权限收紧要同时看文件和父目录

0640 只表示文件本身的读写位，父目录仍然可能让不该访问的人遍历到文件。一个实用的最小方案是：目录归 root 所有并禁止普通用户写入，文件归 root 所有、专用组可读，服务用户加入该组。

# 创建专用组和配置目录；这些命令需要管理员权限
sudo groupadd --system appenv
sudo install -d -o root -g appenv -m 0750 /etc/myapp
# 写入环境文件后，只给 root 写权限，appenv 组只读
sudo chown root:appenv /etc/myapp/myapp.env
sudo chmod 0640 /etc/myapp/myapp.env
# 确认服务用户具备组读取资格，不要直接放宽到 0644
id appuser
stat -c '%U:%G %a %n' /etc/myapp /etc/myapp/myapp.env

权限策略不是“加密”。能读取该文件的进程仍能看到其中的值，所以要把组成员控制在必要范围内，并避免把环境变量完整写进调试日志。

语法、可读性和进程环境分三层复查

排查“变量没有生效”时不要只盯着一条日志。先检查单元语法，再看 systemd 记录的配置，最后确认服务进程实际拿到的值：

# 先做静态检查；失败时先修单元格式，不急着重启
sudo systemd-analyze verify /etc/systemd/system/order-api.service
# 查看 systemd 保存的环境文件引用，避免把 show 当成业务变量泄漏出口
sudo systemctl show order-api.service -p EnvironmentFiles
# 应用需要时输出“已加载/未加载”这类安全摘要，不要打印完整密钥
sudo journalctl -u order-api.service -n 50 --no-pager

如果文件路径正确但启动失败，重点检查目录的执行权限、文件的组权限，以及服务的 User= 是否和预期一致。若单元文件改了却没有效果，先确认执行过 daemon-reload；若环境文件内容改了，通常需要重启服务进程才能让新环境进入进程。

常见问题

EnvironmentFile 能不能写 export？

不要按 Bash 脚本来写。保持每行一个变量赋值，复杂计算放到应用启动逻辑或单独的受控生成步骤中。

为什么文件改了，服务还是旧值？

环境变量属于已启动进程的快照。修改文件后先确认路径和权限，再重启服务；只执行 daemon-reload 不会替换已经运行进程的环境。

把文件设成 0644 是否更省事？

通常不应该。0644 会让所有本地用户读取配置内容，服务专用组只读的 0640 更容易收敛访问范围；若服务用户仍读不到，应修正组成员和父目录权限，而不是直接放宽文件。