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時間以上待つだけでも試しましたが、問題はまだ残っています。
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インストールの一部ではありません。これは、サードパーティによる追加であり、システムには存在しないため、推測することしかできませんが、私は言うでしょう:
スクリプトが何をするかを見つける方法:
ターミナルウィンドウを開き、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」であり、バニラでの使用に安全なダウンバージョンです)。ファイルの場所を手動でルートするよりも便利な場合があります。
背景:
私はファイルの中を見て、数週間前にインストールしたSave to Kindleアプリケーションの一部を学びました。アプリのアンインストーラーは/ Applicationsにあるため、.shを直接削除する代わりにアンインストーラーを使用しました。働いた。
chown
を使用して/var/spool/stkPrinter/username/stkPipe
にある通信パイプを所有することにより、コンピューターで同じ問題を解決しました。
この問題は、新しいドライブに移行した後にパイプの所有権(おそらくアクセス許可も?)が変更されるために発生します。スクリプト/usr/bin/stkLaunchAgent.sh
には、基本的な権限/所有権チェックが組み込まれていますが、十分に機能していません。パイプにアクセスしようとするwhile true
ループになり、ログはエラーメッセージに完全に追い越されます。
Time Machineのバックアップが不可解なほど大きくなっていることに気付かなかったとしても、私はこれに気づかなかったでしょう。システムログを見て、何百万もの行が同じことについて不平を言っているのを見ました。ログファイル/var/spool/stkPrinter/username/stkPrint.log
のサイズは15GBでした!
システムをCrucial M4 SSDに移行した後も同じ問題が発生しました。 /usr/bin/stkLaunchAgent.shを削除して「解決」しました。ファイルに直接関連する起動デーモンはなかったためです。
私はまだそのファイルがどこから来たのか、なぜこれが起こったのか知りたい...