☰

“停止作业”到底是什么，如“停止作业正在运行...”？

tag-icon • tag-icon systemd shutdown
“停止作业”到底是什么，如“停止作业正在运行...”？

发出关闭命令后，有时会收到如下状态消息：

A stop job is running for Session 1 of user xy

然后系统挂起一段时间，或者永远挂起，具体取决于???

那么到底什么是“停工”呢？

另外，为什么它有时会相当准确地估计所需的时间，而有时却可以永远运行？

答案1

systemd 在内部按照“作业”队列进行操作。每个工作（稍微简化一下）是要采取的操作：停止、检查、启动或重新启动特定的操作单元。

当（例如）您指示 systemd 启动一个服务单位，它根据单元要求和依赖性，为实现该目标所需的任何单元（服务单元、安装单元、设备单元等）制定停止和启动作业列表，并根据单元排序关系对它们进行排序，解决并（如果可能）修复任何自相矛盾，并且（如果最后一步成功）将它们放入队列中。

然后它尝试执行排队的“作业”。

正在为用户 xy 的会话 1 运行停止作业

那个单位显示名称这是Session 1 of user xy。这将是（从显示名称来看）会议单位，不是一个服务单元。这是由 systemdlogind程序及其 PAM 插件维护的用户空间登录会话抽象。它（本质上和理论上）是该用户在某处作为“登录会话”运行的所有进程的分组。

已排队的作业是stop。这可能需要很长时间，因为 systemd 的人错误地合并了会话挂断与会话关闭。他们破坏前者以使后者工作，作为回应，一些人改变 systemd 来破坏后者以使前者工作。 systemd 的人们确实应该认识到它们是两个不同的东西。

在您的登录会话中，您有一些忽略SIGTERM或需要很长时间才能终止的事情，一旦它看到SIGTERM。具有讽刺意味的是，前者是某些作业控制外壳的长期行为。当登录会话领导者是这些特定的作业控制外壳时，终止它们的正确方法是告诉它们会话已经结束挂了，于是他们终止了所有他们的作业（与内部 systemd 作业不同类型的作业），然后自行终止。

实际发生的情况是 systemd 正在等待单元的停止超时直到它诉诸于SIGKILL.当然，这个超时是每个单元都可以配置的，并且可以设置为永不超时。这就是为什么人们可能会看到不同的行为。

进一步阅读

答案2

这些消息来自 systemd，它是一个启动和停止作业的 init 系统。作业可以是守护进程，但也可以是一些小任务，例如安装和卸载磁盘、删除 /tmp 或在启动时保存和恢复屏幕亮度。systemctl list-units给你这个想法。 Systemd 使用“单位”和“工作”来表示相同的意思。

当作业停止时（如 ）systemctl stop ...，问题是在声明失败并使用信号终止作业进程之前要等待作业完成多长时间SIGKILL。SIGKILL除非必须，否则我们真的不想使用，因为它没有给进程干净退出的机会。对于某些进程来说，几秒钟可能有足够的时间来声明故障，对于数据库等其他进程来说，可能需要大量的网络和磁盘 I/O 才能让作业干净地停止，因此我们可能会给这些单元几分钟的时间来干净地关闭。

您在关闭时看到的内容相当于systemctl stop $UNIT_NAME需要一些时间才能运行。有一个计数器显示经过的秒数以及发出 SIGKILL 之前的最大等待时间，并且无论如何都会继续关闭。

除非有充分的理由预计会出现长时间延迟，否则这通常表明存在某种故障。这可能包括 DHCP 服务器不响应释放，因此释放操作需要超时，或者某些错误导致守护程序永远不会退出。

答案3

某些服务被卡住，systemd 正在等待它退出。 Systemd 可能没有准确估计所需的时间，时间（通常为 90 秒）是 systemd 在失去耐心之前要等待的时间。参见这篇文章：

用户的会话 c2 正在运行停止作业

答案4

“停止作业”是指正在systemd等待特定“作业”停止，例如，它在继续之前等待完成的某些进程。如果您看到“停止作业正在运行...”（等）的警告消息，从技术上讲，这意味着作业队列中有某些内容正在等待处理。

但是，在深入研究整个系统作业队列之前，请记住，有时这些警告消息是以下原因的间接结果：环境因素（事实上​​，该消息甚至在他们的 GitHub 存储库中被引用为可能的错误）。

例如：我们收到与“停止作业”相关的消息，但无法弄清楚为什么......结果是，磁盘空间几乎耗尽，并且它开始使操作系统表现奇怪。

将服务器升级到更大的磁盘并重新启动修复 ;）

相关内容