☰

如何禁用 systemd 的攻击性紧急 shell 行为？

tag-icon • tag-icon boot systemd administration
如何禁用 systemd 的攻击性紧急 shell 行为？

默认情况下，出现最轻微的错误，systemd 就会进入紧急 shell。例如，如果 fstab 上的挂载之一由于某种原因失败，系统将立即无法启动。我管理着数十个不同的生产系统，我发现这种行为非常具有破坏性。 （实际上我认为这是一个重大的设计失败，但这是个人意见）。

我想提高系统启动弹性。最佳情况下，系统应始终启动，缺少驱动程序、安装座等。不应丢弃紧急 shell（仅显示警告），除非给定的错误会使控制台登录绝对不可能。能跑的，就应该跑。

我知道 systemd 自动从 /etc/fstab 生成 *.mount 文件，并且我可以使用 nofail 选项和较小的 x-systemd.device 超时（或自己定义相关的 .mount 文件）。然而这并不能解决我的问题，我想让系统更有弹性，每次都“修补”fstab 不是很方便，而且我不确定还有多少其他可能的“问题”存在，这些问题会导致我的系统无法启动，因为某些地方的某些开发人员认为这足够重要。

在某种程度上，我想重新获得对我的机器的控制权，而不是让 systemd 决定哪个问题严重到足以破坏启动过程。是否可以？

答案1

从字面上看，这只是安装失败，这就是您需要更改的全部内容。

所以你的请求信很容易回复。创建一个嵌入式文件：

# /etc/systemd/system/local-fs.target.d/nofail.conf

# Clear OnFailure= (set it to nothing)
[Unit]
OnFailure=

我相信除了 linux sysvinit 因允许这种部分故障情况而已经遭受的问题之外，这不会增加新的问题。

然而你也指出了如何长的systemd 应等待指定的块设备变得可用。如果不提供整个 fstab 生成器的替代品，我看不出有什么办法可以配置它。https://www.freedesktop.org/software/systemd/man/systemd.generator.html

如果在这里转储大量不太广泛使用的代码，似乎不太可能提高系统的弹性。我认为最接近的解决方案是修补现有的 fstab 生成器。它并不复杂，我怀疑你可以摆脱它/跟上任何重大的变化。

从技术上讲，如果你的发行版有一个独立的mountallsysvinit 脚本，您可以尝试将其挂钩。但这将显着改变启动过程 - 实际上更多的叉子的。我不会推荐这种方法。

https://unix.stackexchange.com/a/393711/29483

如果你搜索单元文件，只有很少的方法可以让启动回退到emergency.target.通常是当 .mount本地文件系统的某个单元发生故障时，导致local-fs.target 失败。或者当您的 initramfs 无法挂载根文件系统时，如果您的 initramfs 使用 systemd。

local-fs.target有OnFailure=emergency.target。它会失败，因为本地文件系统的单元会自动添加到 local-fs.target 的 Requires 列表中（除非它们有 DefaultDependencies=no）。

$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount

答案2

noauto通过向其条目添加挂载选项来关闭对引导操作不重要的任何文件系统的自动挂载/etc/fstab：

/dev/sdxy /u01 nfs defaults 0 0

到：

/dev/sdyx /u01 nfs noauto 0 0

然后在启动后使用以下行挂载文件系统/etc/rc.local：

mount /u01

此示例使用 NFS，但也适用于从文件服务器导入的 LUN。

答案3

也许试试这个？

systemctl mask emergency.service
systemctl mask emergency.target

相关内容