我知道systemd提供了一种很好的机制来覆盖包提供的单元文件来影响服务配置/行为。这通常是通过使用以下命令来完成的
sudo systemctl edit <unitfile>创建覆盖conf文件的步骤
/etc/systemd/system/<unitfile.d>/Systemd还提供了一种单独的机制来定义模板单元文件,并将其实例化以在运行时创建特定于实例的单元。这需要将模板文件命名为
<servicename>@.service然后将其实例化为
systemctl start <servicename>@<instancename>现在,我想将包提供的服务作为多个单元实例运行。我想避免创建我自己的模板单元文件,所以我试图看看包提供的单元文件是否可以被覆盖以创建模板单元文件。
根据我的理解,模板单元文件有一个与常规单元文件不同的命名约定,因此我认为不能通过将它放在/etc/systemd/system中来覆盖包提供的单元文件。
有什么明确的方法来达到我想要做的事情吗?
特定场景: grafana包安装grafana-server.service单元文件。我想在我的机器上运行两个grafana实例-分别用于DEV和STG。我做到了这一点:
但是,这会破坏grafana提供的服务单元文件中的链接,如果它们在我升级时增强了服务文件,我将需要再次进行此活动。我的目标是避免这种直接依赖,而是将其转换为覆盖依赖。
有什么想法吗?
发布于 2017-10-22 14:20:25
对于下面这两个选项,首先在/etc/systemd/system上重写grafana-server.service (没有@),并抑制ExecStart (假设它使用该选项)使其没有启动。在/etc/systemd/system/grafana-server.service.d/10-disable-execstart.conf上:
[Service]
ExecStart=
WorkingDirectory=/path/to/your/confdir创建一个与您的设置相对应的grafana-server@.service,配置为[Unit]和[Service]:
[Unit]
PartOf=grafana-server.service
ReloadPropagatedFrom=grafana-server.service这些应该将grafana服务器启动/停止/重新启动绑定到所有实例。这个魔术并没有很好的文档化,但是如果您将<instance_name>.conf文件放在您的/path/to/your/confdir上,那么所有这些实例都将自动绑定!
如果希望保存包服务文件中的所有更新优点,但接受维护自定义实例选项,请从泛型中为每个实例名称创建一个符号链接。
/lib/systemd/system/grafana-server.service至
/etc/systemd/system/grafana-service@<instance>.service然后仅重写实例的特定选项。
/etc/systemd/system/grafana-server@<instance>.service.d/99-my-options.conf确保将以下配置添加到[Unit]和[Service]到99-my-options.conf中:
[Unit]
PartOf=grafana-server.service
ReloadPropagatedFrom=grafana-server.service这将为每个实例假定所有grafana-server.service选项,并使用99-my-options.conf文件上的所有选项覆盖它们,并将启动/停止/重新启动操作绑定到grafana-server.service。
两种选择,如果您运行
systemctl start grafana-server.service所有具有/path/to/confdir/<instance>.conf文件的实例都将被启动。同样的情况也适用于stop和restart,您总是可以通过使用它们的grafana-server@<instance>服务名称来单独管理它们。
https://serverfault.com/questions/844202
复制相似问题