测试看门狗的好方法是什么(故意使系统过载的脚本或命令)

测试看门狗的好方法是什么(故意使系统过载的脚本或命令)

我有一个硬件看门狗,有什么好方法来测试它是否确实有效?是否有一个标准脚本或类似脚本将我的系统设置为无限循环以占用所有资源或类似脚本以触发硬件看门狗?

答案1

测试看门狗的一种简单方法是触发内核恐慌。这可以通过 root 身份完成:

echo c > /proc/sysrq-trigger

内核将停止响应看门狗 ping,因此看门狗将触发。

SysRq是一个“神奇”的组合键,您可以点击它,无论内核正在做什么,内核都会响应它,除非它完全锁定。它也可以通过回显字母来使用/proc/sysrq-trigger,就像我们在这里所做的那样。

在这种情况下,该字母c表示执行系统崩溃并进行故障转储(如果已配置)。

您可以找到以下文档SysRq 这里

答案2

如果您想测试看门狗是否正常工作并且正在用户空间中运行看门狗进程(而不是在内核线程中运行的内核看门狗),只需终止或停止该进程即可。这将模拟一个无响应的系统。请注意,硬件看门狗是不是其中硬件正在重置计时器。硬件看门狗是一种用硬件实现定时器的看门狗。无论哪种方式,软件都会定期重置看门狗定时器。

测试看门狗是否已装备但未激活的另一种典型方法是简单地打开它:

# cat >> /dev/watchdog

这假设没有看门狗进程正在运行。一旦打开,看门狗定时器就会启动。因为cat只是打开它并且不会向其中写入任何内容(它正在读取stdin,等待永远不会到来的输入),所以计时器最终将到期并且系统将重置。


即使在重负载下,系统通常不会锁定到看门狗超时的程度。看门狗的设计目的是在系统出现故障时重新启动系统无法恢复的,或者至少在一定时间内无法恢复。这可能是由硬锁定引起的,例如极高的内存压力或阻塞的设备上的交换目标。

计算机的 CPU 核心数量是有限的。忽略 SMT,每个核心在任何给定时刻只能运行一个进程。为了防止进程占用太多时间,内核调度程序指定了一个时间片。每个进程都可以在其时间片内运行,但是一旦它过期(或者进程自愿让出或执行了阻塞系统调用),内核将自动抢占它并开始运行另一个进程。这种设计意味着一个进程可以绝不仅通过使用大量 CPU 来阻止另一个进程运行。只要内核健康,情况就是如此。

在用户空间中运行的进程可以总是被内核抢占。它无法阻止这种情况发生。它可以决定用完其整个时间片,从而保证系统处于 100% 负载,但它不能阻止内核让其他进程轮流使用。但是,如果由于页面错误、信号、系统调用等原因运行在内核空间,并且出现问题导致内核无法满足请求并返回用户空间,则进程将被锁定,调度程序将无法执行得到一个跑步的机会。如果这种情况发生在所有内核上,看门狗将没有机会运行,并且计时器最终将超时,从而在此过程中重置系统。

答案3

过去,这perl -e '1 while 1'会让系统变得非常繁忙,但对于 64 核或其他类型的多处理器系统来说,这简直就是一个难题,并且不会真正消耗内存。一种方法(在 Linux 上)是在内存不足杀手之前创建进程,这样系统最终就会崩溃。实现此目的的一种方法是在单个进程中分配尽可能多的内存,生成一堆工作线程,并让这些线程对所有分配的内存进行随机内存访问。然后你有一些 shell 循环尝试启动大量这样的进程,所有这些进程都会占用尽可能多的内存。有人可能已经按照这些思路写了一个脚本。

https://github.com/thrig/scripts/blob/master/bench/usemem.c

它使用自定义 RNG,可能可以用rand()线程中的调用来替换。有一段时间没有在 Linux 上编译它了,因此-D可能需要各种定义来安抚 Linux 上的编译器。

相关内容