锁定该进程（忽略SIGKILL）是可运行的（不是僵尸或处于不间断的睡眠状态）。它处于什么状态？

我有一个进程，现在已经有几次停止响应了，并且似乎已完全锁定。它不会响应任何使用gdb进行strace或偷看的尝试（gdb挂在wait4（）syscall上）。该进程是可运行的，并且不等待syscall（/ proc / X / syscall：）running或处于不间断的睡眠状态（/ proc / X / status：）State: R (running)。

这个过程到底处于什么状态？这可能是某种类型的内核错误吗？

该过程是redis，现在已经发生了几次。看来，唯一可以杀死该进程的是重新启动。操作系统为美分7。

编辑：内核版本是3.10.0-123.13.2.el7.x86_64。尝试更新到3.10.0-229.11.1.el7，以查看是否有任何区别。

process linux-kernel redis

— 异化
source

它使用什么版本的GDB？根据stackoverflow.com/questions/8978777/…，较新的版本可能会更好。

— 格雷格·布雷

目前，由于挂起的特殊方式，调查似乎更多地是在内核方面，但是如果您不介意，可以添加一些Redis特定信息吗？进程阻塞时正在做什么，诸如此类。我通过Twitter从Nick Craver获得了一些信息，显然，Redis在发生这种情况时正在加载大型数据集，是重新启动进程还是以其他方式（例如，通过DEBUG RELOAD或流水处理大量数据）加载了数据集。）？谢谢。

@antirez该数据集由另一个redis实例的rdb副本加载。锁定发生在redis启动并读取巨型rdb之后。值得注意的是，它有时并不总是锁定。

— 2015年

发生IO错误时，我只会遇到此类问题。您能告诉我们有关dmesg输出的信息吗？

— 1

什么是/proc/<pid>/stack（和/proc/<pid>/task/*/stack）包含哪些内容？这个过程有几个线程吗？

— 斯特凡Chazelas

wait4是一个系统调用，指示进程正在等待其子终止之一。这可能会指出信号处理方面的一些问题。

有点残酷，但是您可以尝试终止应用程序的层次结构：kill -15 -$YourRedisPID。本-前PID手段“的PID和它的孩子。” 由于似乎正在等待孩子的解雇，因此它可能会解锁。

如果它不起作用，让我们更深入地检查：使用以下命令查找信号处理状态 grep ^Sig /proc/$YourRedisPID/status

您会看到一些类似的内容：

SigQ:   8/62777
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000080
SigCgt: 0000000180004023

如内核源代码“ fs / proc / array.c”中所定义，“ SigQ”是待处理信号的数量/待处理信号的限制。

如果信号数量过多，则可能表明您的“ SIGKILL”根本没有被处理。我仍在检查“ kernel / signal.c”文件以了解这些特殊信号的信号管理。

为了直接了解输出，请尝试以下一种代码： awk 'BEGIN{print "ibase=16;obase=2;"} /^Sig...:/{ print toupper($2)}' /proc/$YourRedisPID/status | BC_LINE_LENGTH=0 bc

这输出我：

0
0
10000000
110000000000000000100000000100011

让我们开始发送此输出。我将根据需要更新帖子。

— 阿德里安·M。
source

该进程不在wait4（）中，尝试访问该进程时gdb挂在wait4（）上。该进程本身不在任何系统调用中。而且，挂起进程没有孩子。不幸的是我不得不重启盒子。问题再次发生后，我会收集您要求的数据。

— 2015年

输出在这里：gist.githubusercontent.com/alienth/23685ad2ea46a7eade56/raw/… 再次，proc忽略了SIGKILL。它不在系统调用中。Proc还忽略了SIGTERM。

— 2015年