web-dev-qa-db-ja.com

bashプロセスは90％のCPUを使用し、コンピューターの再起動時に戻ってきます

2008年後半のユニボディMacBook（8 GBのRAM、OS X 10.7.4を実行）の古いHDDをOCZ Vertex 3 SSDに交換しました。これを行った後、Lionをインストールし、Time Machineバックアップからデータを復元しました。

約90％のCPUを永続的に使用する「bash」という名前のプロセスを除いて、すべて問題ありません。

アクティビティモニターを使用して強制終了すると、すべてが正常に戻りますが、コンピューターを再起動するたびに、プロセスが戻ってきます。

私はPRAMを消去し、コンボパッケージから10.7.4を再インストールし、2時間以上待つだけでも試しましたが、問題はまだ残っています。

macosbashprocess
7
Sano

MacOS 10.15でzshに置き換えられるまで、bashはMacオペレーティングシステムの標準シェルでした–つまり、オペレーティングシステムのDarwin基盤とインターフェースする標準プログラム（技術的には、/bin/shはMacの標準シェルですが、 OS X 10.3からmacOS 10.15への/bin/bashのコピー）。これは、Terminal.appウィンドウ（対話型シェル）を開いたときに起動されるプロセスです。

bashは、ターミナルウィンドウなしで起動することもできます–非インタラクティブシェル–たとえば、シェルスクリプトを実行するためにファイル接尾辞.sh。その場合がそうです–bashがスクリプト/usr/bin/stkLaunchAgent.shを実行しており、このスクリプトの何かがシステムをビジー状態にしています。

現在、この質問が行われた時点では、/usr/bin/stkLaunchAgent.shはOS Xインストールの一部ではありません。これは、サードパーティによる追加であり、システムには存在しないため、推測することしかできませんが、私は言うでしょう：

  • その名前の部分「LaunchAgent」とそれがシステムで始まるという事実から、それはLaunchAgentによってトリガーされる-OS Xによって使用される小さな定義ファイル 'launchd：スケジュール、起動、またはその他のイベントでスクリプトおよび非インタラクティブプログラムを開始するためのシステムメカニズム。その部分は、経験に基づく推測と見なされます。
  • vertex SSDのインストールで問題が始まったという事実と、SSDとHDの決定的な違いが最初であるという事実から、スクリプトが起動するスクリプトへのデフラグと同様の低レベルの介入が行われていません。問題のエージェントは、Vertex SSDが受け付けないドライブで何らかの操作を実行しようとしている可能性があります。これにより、スクリプトが実行され、bashがビジー状態になります。さて、thatの部分はワイルドでワイルドな推測にすぎませんが…

スクリプトが何をするかを見つける方法：

ターミナルウィンドウを開き、open -e /usr/bin/stkLaunchAgent.shを実行してシェルスクリプトを確認します（このコマンドはTextEditで開きます。最初にアクティビティモニターで終了します）。これにより、何が実行されているかを正確に確認できます。

それを取り除く方法：

LaunchAgentがある場合は、それを取り除く必要があります。 launchdLaunchAgentファイルはplist形式であり、次の場所にあります

  • ~/Library/LaunchAgents –現在のユーザーアカウントのみ
  • /Library/LaunchAgents –すべてのユーザーアカウント
  • /System/Library/LaunchAgents –システムレベルのエージェント（権限によってここに見つけることはできません！）

これらは通常、逆ドメイン表記（tld.domain.process.plist）で命名されます。暴走bashのユーザーアカウントが自分のアカウントであるかどうかに応じて、上記の最初の2つの場所のいずれかで、plistを探す必要があります（Xcodeがインストールされている場合は、簡単にクイックルックできます）。停止する正しい手順は、launchdのプロセスリストから削除することです。

launchctl unload tld.domain.process

これは、プロセスをアンロードして停止します（plistサフィックスを省略していることに注意してください）。

launchdファイルを処理するためのGUIもあります Peter Borg'sLingon （必ず取得してください“ 「Lingon 3」ではなく「Lingon」であり、バニラでの使用に安全なダウンバージョンです）。ファイルの場所を手動でルートするよりも便利な場合があります。

背景：

9
kopischke

私はファイルの中を見て、数週間前にインストールしたSave to Kindleアプリケーションの一部を学びました。アプリのアンインストーラーは/ Applicationsにあるため、.shを直接削除する代わりにアンインストーラーを使用しました。働いた。

4
natekoechley

chownを使用して/var/spool/stkPrinter/username/stkPipeにある通信パイプを所有することにより、コンピューターで同じ問題を解決しました。

この問題は、新しいドライブに移行した後にパイプの所有権（おそらくアクセス許可も？）が変更されるために発生します。スクリプト/usr/bin/stkLaunchAgent.shには、基本的な権限/所有権チェックが組み込まれていますが、十分に機能していません。パイプにアクセスしようとするwhile trueループになり、ログはエラーメッセージに完全に追い越されます。

Time Machineのバックアップが不可解なほど大きくなっていることに気付かなかったとしても、私はこれに気づかなかったでしょう。システムログを見て、何百万もの行が同じことについて不平を言っているのを見ました。ログファイル/var/spool/stkPrinter/username/stkPrint.logのサイズは15GBでした！

1
Aleksandar Mastilovic

システムをCrucial M4 SSDに移行した後も同じ問題が発生しました。 /usr/bin/stkLaunchAgent.shを削除して「解決」しました。ファイルに直接関連する起動デーモンはなかったためです。

私はまだそのファイルがどこから来たのか、なぜこれが起こったのか知りたい...

1
lenuam