现在我有 systemd 服务文件，其中包含 20 多个环境变量，表示为Environment=这是很多重复，我想删除它们，因为我有celery、Gunicorn和celerybeat的 systemd 文件。
我希望included每个单元文件中都有一个文件，似乎执行此操作的一种方法如下：
\n\n正确的方法是创建一个以单元文件命名的目录，并在末尾附加 .d。因此，对于名为 example.service 的单元，可以创建名为 example.service.d 的子目录。在此目录中，以 .conf 结尾的文件可用于覆盖或扩展 system\xe2\x80\x99s 单元文件的属性。
\n
但这仍然让我陷入与服务名称匹配的文件名称中。我的第一个想法是将所有服务符号链接到同一个文件夹，以便gunicorn.d链接celery.d到celerybeat.d。这样每个服务都会有相同的文件，唯一的额外设置就是创建链接。
那么，我应该在这些目录下使用目录级别的符号链接或文件级别的硬链接来执行此操作吗？
\n或者我的做法完全错误，有一些超级简单的方法来处理这个问题，但我还没有找到。
\n使用EnvironmentFile=。每个服务文件一行。
另外，将您的服务转换为可以使用不同实例启动的模板gunicorn@.service单元，例如，拥有一个单元将允许您启动gunicorn@app1.service和gunicorn@app2.service，两者共享大部分相同的参数 \xe2\x80\x93 ，除了通过每个实例的添加或覆盖的内容之外gunicorn@appX.service.d/目录。可以单独控制、启用实例等。
单元可以用来%i引用它们的实例，例如EnvironmentFile=/etc/webapps/%i.env将扩展为“app1.env”。
（实际上，您根本不需要拥有模板单元；您可以反其道而行之，通过拥有几个实际 gunicorn@appX.service单元，然后通过 common 覆盖某些公共参数gunicorn@.service.d/。）
您确实可以在目录 \xe2\x80\x93 内对文件进行符号链接，我可能建议在文件级别执行此操作，因为这将保留为需要特殊配置的奇怪服务添加第二个.d/配置文件的可能性。（而如果您对整个目录进行符号链接，那么所有目录都必须具有相同的内容，没有办法绕过它。）.d/
最近的 systemd 版本支持与实例非常相似的第二种机制，但隐式地用作-层次结构分隔符。如果您有一个名为 的单元foo-bar-baz.service，则配置也将从foo-bar-.service.d/和加载foo-.service.d/。这对于其他单元类型（如 .slice）最有用，但也可用于服务。（与 类似%i，单位可以使用 引用其名称的最后一个破折号分隔的部分%j。）
作为历史记录，systemd曾经有一个.include /path/to/stuff关键字（早于目录的存在.d），但在 v246 中被删除了。