drop-in 覆盖是什么
直接修改软件包自带的单元文件有两个问题：系统升级时会被覆盖，改动丢失；出问题时很难判断哪些是原始定义、哪些是本地改动。drop-in 机制解决的就是这件事：在独立的覆盖目录下放片段文件，systemd 加载时把它合并进主单元，同名键以片段为准。这样既保留了软件包的原始定义，本地调整也集中可查、可单独回滚。它是运维调整服务参数的标准做法。
基本信息
| 覆盖目录 | 与单元同名的目录，后缀为 .d |
|---|---|
| 片段文件 | 目录下的配置文件，可放多个 |
| 合并顺序 | 按文件名排序，后加载的覆盖同名的键 |
| 命名建议 | 用数字前缀管理覆盖优先级 |
| 编辑入口 | 有交互式编辑命令可自动创建片段并重载 |
| 权限 | 写入覆盖目录需 root |
典型使用场景
- 调整资源上限：为高连接数服务放开文件句柄限制而不动原文件
- 追加环境变量：给服务补充环境变量或配置文件路径
- 调整重启策略：按业务重要性改变异常退出后的行为
- 临时排障：加一个只读或调试参数，用完删除片段即可回滚
- 变更留痕：把本地调整集中存放，便于审计与交接
- 多环境差异管理：同一软件在不同环境用不同片段区分
交互方式与手工方式
交互方式与手工方式
systemctl edit myapp.service # 生成片段并自动重载，推荐
# 手工方式：建同名目录后写入片段
# mkdir -p /etc/systemd/system/myapp.service.d
# 片段内容示例：
# [Service]
# LimitNOFILE=65535
# Environment=APP_ENV=prod
systemctl daemon-reload # 手工方式需自行重载
systemctl restart myapp # 让新参数落到进程
systemctl cat myapp # 查看合并后的最终定义
systemctl show myapp -p LimitNOFILE # 核对实际生效值用法要点
| 项目 | 规则 | 常见错误 |
|---|---|---|
| 目录命名 | 单元名加 .d 后缀 | 目录名与单元名不一致则不生效 |
| 片段文件名 | 建议数字前缀加描述 | 排序靠后覆盖靠前，顺序影响结果 |
| 段落名 | 必须与主单元一致 | 写错段落名会报未知段落 |
| 重复键 | 同名键以片段为准 | 期望追加却被整体替换 |
| 生效步骤 | 重载后重启服务 | 只重载不重启，运行中的进程不变 |
| 回滚方式 | 删除片段后重载重启 | 忘记重载导致改动看似没撤销 |
片段用的是合并语义：同名键被整体替换而不是追加。对于列表类参数要特别注意这一点——想追加内容可能需要把完整列表写全，或者改用独立的配置目录加载。改完用查看合并结果的命令核对，比盯着两个文件猜要可靠得多。
生成完整副本的编辑方式会复制整份单元文件，之后系统升级带来的新定义不会同步进来，容易与软件包版本脱节。除排障临时使用外，长期调整应坚持用片段覆盖的方式。