☰

调试 ps -ef 为何卡住所需的建议

tag-icon • tag-icon linux process suse troubleshooting
调试 ps -ef 为何卡住所需的建议

我的一些进程消耗 100% cpu。我试图找出哪些脚本导致了它

我尝试运行strace ps -ef：

open("/proc/PID/status", O_RDONLY) = 6
read(6, "Name:\textract\nState:\tR (running)"..., 1023) = 1023
close(6) = 0
open("/proc/PID/cmdline", O_RDONLY) = 6
read(6,

所以它在尝试阅读时陷入困境/proc/PID/cmdline。我尝试了cat一下，结果又卡住了。显然内核里有什么东西被拧进去了；接下来我应该尝试什么？

注意：重新启动不起作用——如果我手动关闭，问题会再次出现。我使用的是 SUSE Linux Enterprise Server 11 (x86_64)、Linux 2.6.27.19

编辑:ps -e产生输出，我发现 s 太多了grep。 s的数量grep各不相同：250、450，现在我看到大约 520 个 grep。我回溯了一下，发现这是一个cron脚本的结果。我仍然需要理解那些 cron 脚本。是的，top显示结果。两天前我们手动关闭了服务器。系统从最近两天开始运行。我看到一些预言机的东西一直在运行。我刚刚做了内存测试，没有发现任何错误

答案1

就在昨天。问题是，一个进程处于“不间断睡眠”状态，显示为 statusD在顶部。 ls /proc/ 不会返回并且不可中止。 ps -ef 不会返回且不可中止。

如果重新启动没有帮助，您的 DVD 或硬盘上可能有坏扇区，并且进程 PID 正在启动期间尝试读取该扇区。因此，从技术上讲，重新启动会有所帮助，但错误会自动重新发生。

向 top 检查进程是否确实处于状态 D，然后从那里继续。启动计算机而不调用此进程（救援系统）。然后启动程序跟踪它并查看它访问了哪些文件。我打赌有一个文件有坏扇区。

答案2

看起来 grep 被挂起，并且由于 cron 作业调度，另一个进程将在一定时间后变得活动（如 crontab 中所写）。多个进程会导致系统无响应

尝试以下调试方法：

  • 更改 crontab 条目以增加脚本间隔（以便挂起的脚本不会被执行多次）
  • 记录top在一段时间内的输出
  • 从最上面的日志开始遍历进程树，然后找到它挂在的进程
  • 然后遍历调用相同事物的代码形式。

相关内容