そして、できれば本当に最終的な編集：Mountain Lionにアップグレードした後、問題は修正されたようです。

最終編集：問題は常に発生するわけではありません。時々、発生するまで数日待たなければなりません。したがって、異なる条件（セーフモードまたは一部のソフトウェアを無効にした状態）でテストするのは困難であり、これを修正するために異なる条件を整えるのに何日も費やす価値はないと判断しました。Graham Perrinの提案は、汎用ログには見られない、再起動/再起動の問題に関する特定の情報を見つけるのに最も役立ちました。

一部のログエントリは、下部の[編集]にあります。

OS X 10.7.4を実行している2010年半ばの15インチMacBook Pro。マシンを再起動またはシャットダウンしようとすると動作しない場合があります-画面が灰色に変わり、回転するホイールが表示されますが、マシンの電源が切れないため、数分後に電源を押してマシンをシャットダウンする必要がありますボタン。

それは毎回起こるわけではなく、セッション中に使用されたソフトウェアを問題と関連付けることはできません。実際、これをテストするときに、マシンを起動した直後にマシンをシャットダウンしようとすると、これが発生することがあります。

正常なシャットダウン/再起動を妨げているものを確認するにはどうすればよいですか？いくつかのログファイルを調べる必要があると思いますが、どのログファイルと何を探すべきかわかりません。

編集：Graham Perrinが示唆するように、nvramに詳細な開​​始/シャットダウン設定を追加し、最終的にマシンが再起動でスタックするようになりました。画面に詳細なエントリが表示され、再起動後に/var/log/launchd-shutdown.logでそれらが見つかりました。WindowServerには何らかの関係があるようです。以下は、最初の3列が削除されたログファイルの最後です（最初の列には整数値が増加し、2番目には「1」、3番目に「com.apple.launchd」のエントリがありました）。

234 com.apple.WindowServer   Dispatching kevent callback.
234 com.apple.WindowServer   Job has not died after being killed 2 seconds ago. Simulating exit.
234 com.apple.WindowServer   Dispatching kevent callback.
234 com.apple.WindowServer   EVFILT_PROC event for job.
1 com.apple.launchd         KEVENT[0]: udata = 0x107827a90 data = 0x0 ident = 234 filter = EVFILT_PROC flags= 0x0 fflags = NOTE_EXIT
234 com.apple.WindowServer   Reaping
234 com.apple.WindowServer   Simulated exit: <rdar://problem/9359725>
234 com.apple.WindowServer   Exited 22.016701 seconds after the first signal was sent
0 com.apple.WindowServer     Exited while shutdown in progress. Processes remaining: 0/0
0 com.apple.WindowServer   Job was last to exit during shutdown of: System.
0 com.apple.WindowServer    Total rusage: utime 0.000000 stime 0.000000 maxrss 0 ixrss 0 idrss 0 isrss 0 minflt 0 majflt 0 nswap 0 inblock 0 oublock 0 msgsnd 0 msgrcv 0 nsignals 0 nvcsw 0 nivcsw 0
0 com.apple.WindowServer  Closing receive right for com.apple.windowserver.active
0 com.apple.WindowServer  Mach service deleted: com.apple.windowserver.active
0 com.apple.WindowServer  Closing receive right for com.apple.windowserver
0 com.apple.WindowServer   Mach service deleted: com.apple.windowserver
0 com.apple.WindowServer    Removed
1 com.apple.launchd      System: No submanagers left.
1 com.apple.launchd    System: Removing.
1 com.apple.launchd   System: Removing job manager.
1 com.apple.launchd    System: Userspace shutdown finished at: Wed Aug  1 08:53:12 2012
1 com.apple.launchd   System: Userspace shutdown took approximately 22 seconds.
1 com.apple.launchd   VM statistics (now - orig): Free: 28472 Active: -21833 Inactive: -1038 Reactivations: 0 PageIns: 25 PageOuts: 0 Faults: 1654 COW-Faults: 335 Purgeable: -849 Purges: 0
1 com.apple.launchd   System: Stray process at shutdown: PID 234 PPID 1 PGID 234 WindowServer
1 com.apple.launchd       System: About to call: reboot(RB_HALT).

他の答えを補完する…

再起動またはシャットダウン中に詳細モードを観察する

Mac OS X：シングルユーザーモードまたは冗長モードで起動する方法

–冗長モードで起動した場合、再起動またはシャットダウンも同様に冗長になります。

ヒント：冗長モードでの処理が特定のポイントを超えて進行しないようであれば、次のいずれかの5分前に許可してください。

• 再起動の強制（Command-Control-Power）; または
• 強制的にシャットダウンします（電源キーを押し続けます）。

強制的な再起動が成功しない場合、問題の原因の別の手がかりになる可能性があります。

問題指向ではありませんが、関連する質問：誰でも詳細なシャットダウンメッセージを解釈できますか？

ここでの問題指向のケースは、lupinchoの方が簡単に解決できるはずです。茶葉が少ない。

Command-Vをキー入力せずに詳細モードで起動するには

プリファレンスはNVRAMに保存できます。ターミナルで次のコマンドを入力し、管理者パスワードを入力する準備をします。

sudo nvram boot-args="-v"

システムの次の起動は冗長になります。

sysdiagnose

各再起動またはシャットダウンの前に、ターミナルで：

sudo sysdiagnose

時間がかかりますが、すべての実行の結果を調査する必要はありません。問題が発生した場合にのみ注意してください。

lupinchoのような場合：

• を実行すると、再起動またはシャットダウンする前にsysdiagnose問題が明らかになる場合があります
• sysdiagnoseの最終結果は、強制的な再起動またはシャットダウンに続く場合があります。

より具体的にはsysdiagnose、特定のポイントを超えて実行が失敗した場合、そのポイントを知ることで、根本的な問題の感覚をつかむことができます。

実行中に、次のキーの組み合わせを繰り返し使用して、物事が進行しているかどうかを確認できます。

• Control-T

ルーチンのallmemory部分についてはsysdiagnose、Appleの2分間の見積もりはかなり不正確かもしれません。我慢して。

sysdiagnose特定のポイントを超えて進行しないと思われる場合は、次のキーを押します。

• Control-C

Control-Cの繰り返し使用が中止sysdiagnoseに失敗した場合、（Mountain Lionでの経験では）オペレーティングシステムの再起動またはシャットダウンの試行が失敗することはほぼ確実です。

シャットダウン監視

Finderで、次の場所に移動します。

/private/var/log/shutdown_monitor.log

通常、このファイルは空ですが、問題のあるシャットダウン後に関心のある項目が含まれている場合があります。（この分野での経験はほとんどありません。）

シャットダウン時の唯一の浮遊プロセスがWindowServerの場合

シャットダウン時に浮遊プロセスが発生することは珍しくありません。迷走は、殺されない場合にのみ問題となる可能性があります。

WindowServerが強制終了されておらず、この特定の迷走がシャットダウン障害の原因であると思われる場合：サードパーティのソフトウェアがWindowServerプロセスを標準外で使用しているかどうかを自問してください。

Mountain LionのWindowServerのGrabFSビューのクイックルック、2つのディスプレイ：

Lionが似ている場合、シャットダウンの失敗の原因はWindowServerを超えているという私の直感です。

launchctlの結果に基づく推測

マシンは正常に動作していますが、次のコマンドに対する応答は何ですか？

sudo launchctl list | grep  --invert-match com.apple

アップル以外のソフトウェアが問題に寄与しているかどうか疑問に思います。ウイルス対策、マルウェア対策ソフトウェア？

LionからMountain Lionへのアップグレード後

目指す：

/private/var/log/com.apple.launchd/launchd-shutdown.system.log

デフォルトはシャットダウンごとに1つのログで、最大2つのログがあるようです。

/private/var/log/com.apple.launchd/launchd-shutdown.system.log.1

強制再起動または強制シャットダウンに続いて、2つのうち最新のもののコピーを保存することを選択できます。複数回にわたって強制が必要な場合は、ファイルを比較して、パターンが出現するかどうかを確認できます。

一般的に

サードパーティのソフトウェアに問題が発生する可能性を排除しないでください。品質をリリースすることさえ可能です。Little Snitchはよく書かれていて、広く尊敬されているかもしれませんが：

• この質問にあるような問題が拡大または不可解になる場合、Apple以外のカーネル拡張は注意に値します。

OS X 10.8のビルド12A269がリリースされる前の約2週間、特に困難な状況での動作をシャットダウンすることに注意してテストしました。私はWWDC 2012のビデオを見たことはありませんが、Appleは非常に困難な状況を除いてすべての力の必要性を防ぐために非常に一生懸命に働いていると感じています。

デビッド・デルモンテの答えに基づいて

少なくともMountain Lionでは、シャットダウンロギングが開始される前に、Little Snitch 3.0 Preview 2（3857）のロードが非常に早い時期に表示されます。このKEXTに関連する事柄がシャットダウン時間の前後に同様に遅い場合、ディスク上の通常のログファイルでは問題が明らかにならない可能性があります。

ライオンまたはマウンテンライオンのいずれかで問題の原因を発見した場合は、喜んでお知らせします。

それまでの間、賞金に大きな感謝を込めて、最後に考えました。

kextstat -l | grep --invert-match com.apple

アプリケーション->ユーティリティに移動し、コンソールを開きます

system.logファイルを見てください。そこに何かを見つけることができるかもしれません。

pmset -g assertions パワーアサーションの要約を取得します。

$ pmset -g assertions
Assertion status system-wide:
   PreventUserIdleDisplaySleep             0
   CPUBoundAssertion                       0
   DisableInflow                           0
   ChargeInhibit                           0
   PreventSystemSleep                      0
   PreventUserIdleSystemSleep              1
   ExternalMedia                           1
   DisableLowPowerBatteryWarnings          0
   EnableIdleSleep                         1
   NoRealPowerSources_debug                0
   UserIsActive                            0
   ApplePushServiceTask                    0

Listed by owning process:
  pid 153: [0x00000099012c023b] PreventUserIdleSystemSleep named: "com.apple.audio.'AppleUSBAudioEngine:Apple Inc.:Display Audio:15261930:2,1'.noidlesleep" 
  pid 19: [0x00000013012c0235] ExternalMedia named: "com.apple.powermanagement.externalmediamounted" 

プロセスのパスは次の方法で確認できますps up $pid。

$ ps up 153
USER          PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
_coreaudiod   153   0.0  0.2  2475000   6740   ??  Ss   Fri05PM  12:17.71 /usr/sbin/coreaudiod

私は以前この問題を抱えていましたが、私のために働く修正を見つけました。私はあなたの質問（問題の原因を確認する方法）に直接答えているわけではありませんが、一見の価値があるかもしれない修正です。

1. 「Macintosh HD>ライブラリ」に移動します
2. 「Java」という名前のフォルダーを削除します
3. 空のごみ箱
4. シャットダウン
5. Java関連の何かを実行すると、Javaを再インストールするように求められます。

その後、シャットダウン時間が改善されるはずです。注：システムの起動直後にシャットダウンすると、シャットダウンが遅くなります。手順を実行してテストしたい場合は、システムの起動後数分待ってからシャットダウンしてください。

1. 周辺機器（USB、FWなど）が接続されていますか？

その場合、すべてを切断し、問題が存在するかどうかを確認することは興味深いでしょう。

1. アクセス許可を修復し、ファイルの整合性を確認しましたか？

これらの助けを願っています。

さらにいくつかのアイデア：

1. 別のユーザーアカウントを作成します。このテストアカウントとしてのみログインします。問題がない場合は、ユーザーソフトウェアに問題がある可能性があります。問題がある場合は、ハードウェアである可能性があります。

2. バッテリー電源を使用して問題を再現してみてください。

3. Appleのシステム管理コントローラーの手順に従ってください-

System Management Controller（SMC）の リセット取り外し可能なバッテリーを備えたMacポータブルのSMCのリセット

パソコンの電源を消します。MagSafe電源アダプタが接続されている場合は、コンピュータから取り外します。バッテリーを取り外します。電源ボタンを5秒間押し続けます。電源ボタンを放します。バッテリーとMagSafe電源アダプターを再接続します。電源ボタンを押してコンピューターの電源を入れます。

私はあなたがリトルスニッチを走らせたことに気づかなかった。LSを削除して、友人の同様の問題を解決しました。試してみることをお勧めします。適切に削除するには、LSインストーラーを再度ダウンロードします。インストーラーを実行しますが、アンインストールを選択します。

なぜこのアプリを使いたいのか興味があります。

私のガールフレンドは、ディレクトリをゴミ箱にドラッグアンドドロップし、ゴミ箱を空にすることで、パラレルのディレクトリを削除しただけでした。しかし、Libraryフォルダー内で再び類似点を見つけ、適切にアンインストールするためのシェルスクリプト（.shファイル）がありました。これにより、長いブートの問題が解決しました。

パラレルは多くの遅い起動の既知の原因であり、ウェブサイトが示すようにアンインストールするのは簡単ではないようです（ディレクトリをドラッグアンドドロップするだけです）。

これが誰かの助けになることを願っています。