☰

bash 进程占用了 90% 的 CPU，计算机重启后又恢复

tag-icon • tag-icon macos bash process
bash 进程占用了 90% 的 CPU，计算机重启后又恢复

我用 OCZ Vertex 3 SSD 替换了 2008 年末的一体式 MacBook（8 GB RAM，运行 OS X 10.7.4）的旧 HDD。完成此操作后，我安装了 Lion 并从 Time Machine 备份中恢复了我的数据。

一切都很好，除了一个名为“bash”的进程一直使用大约 90％ 的 CPU。

如果我通过活动监视器将其终止，一切都会恢复正常，但不幸的是，每次我重新启动计算机时，该进程都会再次出现。

我尝试过清除 PRAM、从组合包中重新安装 10.7.4，甚至只是等待 2 个多小时，但问题仍然存在。

答案1

直到被替换嘚在 macOS 10.15 中，狂欢是 Mac 操作系统的标准外壳——即与操作系统交互的标准程序达尔文底层（从技术上讲，/bin/sh是 Mac 上的标准 shell，但那是从 OS X 10.3 到 macOS 10.15 的副本/bin/bash）。它是打开终端应用程序窗口——一个交互式外壳。

狂欢也可以在没有终端窗口的情况下启动 - 非交互式 shell - 例如执行shell 脚本，通常用文件后缀表示.sh。这里的情况就是如此——狂欢正在运行脚本/usr/bin/stkLaunchAgent.sh，并且该脚本中的某些内容使您的系统保持繁忙。

现在，截至提出这个问题时，/usr/bin/stkLaunchAgent.sh它还不是 OS X 安装的一部分 – 它是某种第三方附加组件，因此不存在于我的系统中，这意味着我只能猜测，但我会说：

  • 从其名称部分“LaunchAgent”以及它从你的系统启动的事实来看，它是由启动代理– OS X 使用的一个小的定义文件'启动，按计划、启动或其他事件启动脚本和非交互式程序的系统机制。这部分我有资格作为有根据的猜测。
  • 从你的麻烦开始于安装 Vertex SSD 的事实，以及 SSD 和 HD 之间的关键区别在于，第一个事实是，它们不接受碎片整理和类似的低级干预，由相关代理启动的脚本可能试图在 Vertex SSD 不接受的驱动器上执行某些操作——这使得脚本保持运行，并且狂欢现在很忙，那部分内容只是一个大胆的猜测，但是……

如何找出脚本的作用：

打开一个终端窗口并open -e /usr/bin/stkLaunchAgent.sh查看 shell 脚本（该命令将在 TextEdit 中打开它 - 首先在活动监视器中终止它） - 这应该可以让您查看正在运行的内容。

如何摆脱它：

如果确实存在 LaunchAgent，那么你必须将其删除。启动LaunchAgent 文件位于清单格式并发现

  • ~/Library/LaunchAgents– 仅适用于当前用户帐户
  • /Library/LaunchAgents– 适用于所有用户帐户
  • /System/Library/LaunchAgents– 系统级代理（按理来说不应该在这里找到！）

它们通常以反向域名表示法 ( tld.domain.process.plist) 命名。根据您失控的用户帐户是否bash属于您，您应该在上面的前两个位置之一中查找可能的 plist（如果您安装了 Xcode，您可以轻松地快速查看它们）。阻止它的正确方法是将其从启动的进程列表

launchctl unload tld.domain.process

这将卸载并停止该过程（请注意省略后缀plist）。

还有一个用于处理的 GUI启动文件，彼得·博格的林贡（确保获取“Lingon”，而不是“Lingon 3”，后者是适合原始使用的简化版本），这可能比手动查找文件位置更方便。

背景：

答案2

我查看了文件内部，发现它是我几周前安装的“保存到 Kindle”应用程序的一部分。该应用程序在 /Applications 中有一个卸载程序，所以我这样做了，而不是直接删除 .sh。成功了。

答案3

将系统迁移到 Crucial M4 SSD 后，我遇到了同样的问题。我通过删除 /usr/bin/stkLaunchAgent.sh 解决了这个问题，因为没有与该文件直接相关的启动守护程序。

我仍然想知道该文件来自哪里以及为什么会发生这种情况......

答案4

chown我通过使用中存在的通信管道解决了计算机上的相同问题/var/spool/stkPrinter/username/stkPipe。

问题发生的原因是，在迁移到新驱动器后，管道的所有权（也许还有权限？）发生了变化。该脚本/usr/bin/stkLaunchAgent.sh确实内置了一些基本的权限/所有权检查，但显然做得不够好。它最终陷入循环，while true试图访问管道，日志完全被错误消息所淹没。

如果我没有注意到我的 Time Machine 备份莫名其妙地变得很大，我甚至不会注意到这一点，那时我查看了系统日志，发现数百万行都在抱怨同一件事。日志文件/var/spool/stkPrinter/username/stkPrint.log有 15GB 大！

相关内容