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

默认情况下，systemd会以最小的错误降到紧急外壳。例如，如果由于某种原因在fstab上的安装之一失败，则系统将立即无法启动。我管理着数十种不同的生产系统，并且发现这种行为非常有害。（实际上，我认为这是一个重大的设计失败，但这是个人观点）。

我想增加系统启动的弹性。理想情况下，系统应始终启动，缺少驱动程序，安装件等。不应丢弃紧急外壳，（只是显示警告），除非给定的错误将使控制台登录绝对不可能。可以运行什么，应该运行。

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

在某种程度上，我想重新获得对计算机的控制权，而不是让systemd决定什么问题足以严重破坏启动过程。可能吗？

实际上，这只是挂载故障，这就是您需要更改的一切。

因此，您的要求书将很容易回答。创建一个插入文件：

# /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使用systemd，则initramfs无法挂载根文件系统。

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

通过noauto在其/etc/fstab条目中添加安装选项，关闭对启动操作非必需的任何文件系统的自动安装：

/dev/sdxy /u01 nfs defaults 0 0

至：

/dev/sdyx /u01 nfs noauto 0 0

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

mount /u01

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

试试这个吧？

systemctl mask emergency.service
systemctl mask emergency.target