☰

systemd 无法启用，并显示“服务是临时的或已生成的”。这个配置有什么问题？

tag-icon • tag-icon systemd service init.d systemctl failed
systemd 无法启用，并显示“服务是临时的或已生成的”。这个配置有什么问题？

一般来说

我一直在网上寻找确实有帮助有关 systemd 和此错误的文档，但其中大部分内容都是针对小众情况进行故障排除，或者过于详细以至于信息毫无用处。我正在尝试设置 1 个简单的自定义服务。这应该是注册然后启用服务的简单问题，但显然 systemd 使这个过程变得比需要的更复杂。

多年来，这一直是我的眼中钉，我终于准备放弃任何托管 systemd 的操作系统，转而使用在实施上并不完全疯狂并将按预期运行简单的初始化脚本。

超出一般范围

在彻底放弃 systemd 之前，我想再试一次。我想详细了解（但以适合初级系统开发人员的范围进行解释）的是

  1. （森林景观，即需要顶层解释，无需技术细节) systemd 管理哪些类型的服务，以及 systemd 如何（按时间顺序）扩展来管理这些服务？
  2. （树景，即在描述中包含技术细节) 这些系统在典型的 Debian 系统上具体位于哪里？
  3. （森林) 符号（或硬）链接如何影响将所有这些系统绑定在一起，如果符号链接没有得到正确管理会发生什么？
  4. （分支视图，尽可能详细，不要保留）systemd 如何管理正在运行的服务（即：它遵循什么样的工作流程）？
  5. （树木）与上一个问题类似，这些不同类型的服务是否分层次启动？（我知道有依赖关系和运行级别...但这些是如何分配到不同的系统级别...即/opt 软件与内核级别）
  6. （分支) 如何确定要使用哪个级别的服务处理程序？
  7. （分支）如何确定应该使用哪个运行级别，以及与服务成功执行相关的附加选项
  8. （分支) 在哪里可以找到单个（工作）示例或将其用作模板？我认为应该存在某种用于不同类型服务的骨架文件夹，但我还没有找到它。
  9. （分支) 如果新服务无法正确创建，可以采取哪些步骤来删除故障服务并启动干净服务？在服务创建失败后，我多次尝试启动干净服务，但显然都被最初失败尝试留下的残留符号链接和其他残留文件阻止了，尽管使用“find”和“ls”（是的，执行 sync 和 echo 3 > cache）彻底搜索并销毁与服务有一点点关系的任何文件，服务仍然会失败。
  10. （树木）为了让生活更轻松，可以快速找到可能破坏 system.d 进程的符号链接（显示绝对路径）

买的稍微一般一点

我的具体错误

  1. systemctl 启用 lidarr.service

    Failed to enable unit: Unit /run/systemd/generator.late/lidarr.service is transient or generated.

  2. /etc/init.d/lidarr.service喵喵的猫

  3. /etc/init.d/ 的 ls

  4. /etc/systemd/system 的 ls，第 1 部分

  5. /etc/systemd/system 的 ls，第 2 部分

  6. /etc/systemd/system 的 ls，第 3 部分

我尝试过的方法

  • 守护进程重新加载
  • 删除失败服务的所有痕迹
  • 清除缓存
  • 删除所有符号链接（我能找到的）
  • Chmod +x 服务
  • 在创建其他符号链接的位置手动创建一个指向服务的符号链接（这种方法在过去偶尔会奏效……同样，systemd 有太多的处理程序，其行为无法预测）
  • 哭，喝点酒
  • 恳求，讨价还价
  • 重新安装整个系统……是的，核选项

求求你，上面加点糖，这样就不会那么混乱了

答案1

我怀疑您放置的文件/etc/init.d/应该存放到/etc/systemd/system/。

移动systemd .service远离文件的位置System V 风格的启动脚本并进入 systemd 单元目录，刷新可用单元并确认您正在使用预期的单元文件：

# mv /etc/init.d/lidarr.service ~/lidarr.service.bak
# cp lidarr.service /etc/systemd/system/

# systemctl daemon-reload
# systemctl cat lidarr.service

(output should mention (only) your unit path at /etc/systemd/system/lidarr.service)

# systemctl start lidarr.service
# journalctl -e -u lidarr.service

输出中可能仍包含您可能有后续问题的其他问题，但至少现在您应该使用您的单元文件。

了解您遇到的问题的关键点：

  1. systemd 单元是远的比简单的 sysv 风格更复杂、更抽象启动脚本systemd 提供了一个自动化工具来生成（并在不再需要时清理）合适的单位文件动态兼容。但是，对于任何给定的单位名称，您只能使用任何一个发电机或者直接管理单元文件。
  2. 如果你自己编写 systemd 单元（通常强烈建议不要自动生成），则 systemd单元文件去往如下路径/etc/systemd/system/-不是与可执行文件混合启动脚本传统上/etc/init.d/由 sysv 风格的 init 使用。

手册系统控制告诉我们以下有关generated状态的信息：

单元文件是通过生成器工具动态生成的。请参阅 systemd.generator(7)。生成的单元文件可能未启用，它们由其生成器隐式启用。

因此，您的错误消息意味着 systemd 自动为您生成单元文件的方法之一正在被使用，从而阻止您使用自己编写的方法。

相关内容