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