Question

我在cloud-init文件中创建了以下systemd单元：

- path: /etc/systemd/system/multi-user.target.wants/docker-compose.service
  owner: root:root
  permissions: '0755'
  content: |
      [Unit]
      Description=Docker Compose Boot Up
      Requires=docker.service
      After=docker.service

      [Service]
      Type=simple
      ExecStart=/usr/local/bin/docker-compose -f /opt/data/docker-compose.yml up -d
      Restart=always
      RestartSec=30

      [Install]
      WantedBy=multi-user.target

当我尝试运行时

sudo systemctl enable docker-compose.service

创建符号链接我得到了这个：

Failed to execute operation: No such file or directory

但我确定该文件位于/etc/systemd/system/multi-user.target.wants

下

Answer 1

检查所涉及的每个文件是否存在且有效：

 ls -l  /etc/systemd/system/multi-user.target.wants/docker-compose.service
 ls -l /usr/local/bin/docker-compose
 ls -l /opt/data/docker-compose.yml
 systemd-analyze verify /etc/systemd/system/multi-user.target.wants/docker-compose.service

还要考虑时机。即使文件在完全启动后仍然存在，/etc/systemd/system/multi-user.target.wants/运行时会cloud-init存在吗？

Answer 2

在单元文件创建之后但在对其进行任何操作之前，应该通知 systemd 有关更改的信息：

systemctl daemon-reload

因此，创建 docker-compose.service 文件的 cloud-init YAML 块应遵循：

runcmd:
- systemctl daemon-reload

Answer 3

我也有同样的需求，但我使用的方法是创建 /etc/systemd/system/unit.service 然后执行 systemctl enable --now unit。

所以我用 write_files 创建了单元文件，并在 text/x-shellscript 部分重新加载和启用，效果很好。（用户脚本最后按顺序运行，虽然我认为不能保证用户数据中的 write_files 键何时被处理。我发现它在 user 之前很难键，因此您无法为 cloud-init 创建的用户设置所有权）。

我认为 runcmd 条目会转换为用户脚本并按列表顺序运行（在其他用户脚本之前或之后），因此如果您不喜欢 x-shellscript 部分，您可以重新加载并启用这种方式。 /var/log/cloud-init.log 是我检查订单的地方，可能还有一个配置文件。

完全披露：我忘记了 systemctl daemon-reload 命令，但它仍然有效。实际上，对于来自 cloud-init 的 systemd 操作有一个警告，因为它本身在 systemd 下运行，并且一些 systemd 命令可能会等待 cloud-init 完成——死锁！

在cloud-init中创建systemd单元并启用它

3 个答案: