И, надеюсь, действительно окончательное редактирование: после обновления до Mountain Lion проблема кажется исправленной, надеюсь, навсегда.

Окончательное редактирование: проблема не возникает постоянно, иногда мне приходится ждать несколько дней, чтобы это произошло. Таким образом, это трудно проверить в других условиях (например, в безопасном режиме или с некоторым отключенным программным обеспечением), и я решил, что не стоит тратить дни на обдумывание различных условий, чтобы исправить это. Предложения Грэма Перрина были наиболее полезными для поиска конкретной информации о проблемах перезапуска / перезагрузки, которых нет в журналах общего назначения.

Некоторые записи журнала находятся в Редактировать внизу:

Середина 2010 года 15-дюймовый MacBook Pro, работающий под управлением OS X 10.7.4. Иногда при попытке перезагрузить или выключить аппарат, он не работает - экран становится серым, вращается вращающееся колесо, но машина не выключается, поэтому через несколько минут мне нужно выключить машину, нажав кнопку питания. кнопка.

Это происходит не каждый раз, и я не могу связать какое-либо программное обеспечение, используемое во время сеанса, с проблемой. Фактически, при тестировании этого иногда случается, когда я пытаюсь выключить машину сразу после ее запуска.

Как проверить, что мешает постепенному выключению / перезагрузке? Я предполагаю, что мне нужно искать в некоторых файлах журналов, но я не уверен, какие из них и что искать.

Редактировать: Добавлен подробный запуск / выключение в nvram, как это было предложено Грэмом Перрином, и в итоге машина зависла при перезагрузке. Я увидел несколько подробных записей на экране и после перезагрузки нашел их в /var/log/launchd-shutdown.log. Похоже, что WindowServer может иметь к этому какое-то отношение. Ниже приведен конец этого файла журнала с удаленными первыми 3 столбцами (первый имел несколько растущих целых чисел, второй имел записи «1», а третий - «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: как запустить в однопользовательском или подробном режиме

- если вы начнете в подробном режиме, то перезагрузка или выключение будет аналогичным подробным.

Подсказка: если вещи в многословном режиме не достигают определенного уровня, подождите, может быть, пять минут до того:

• принудительный перезапуск (Command-Control-power); или
• принудительное отключение (нажмите и удерживайте кнопку питания).

Если принудительный перезапуск не удастся, это может быть еще одним объяснением причины проблемы.

Смежный вопрос, хотя и не проблемный: может ли кто-нибудь интерпретировать подробные сообщения о завершении работы?

Проблемно-ориентированный случай здесь должен быть проще для lupincho. Меньше чайных листьев.

Для запуска в подробном режиме без нажатия клавиши Command-V

Предпочтение может быть сохранено в NVRAM. Введите следующую команду в Терминале и будьте готовы ввести свой пароль администратора:

sudo nvram boot-args="-v"

Следующий запуск системы будет многословным.

sysdiagnose

Перед каждым перезапуском или выключением в Терминале:

sudo sysdiagnose

Это отнимает много времени, но вам не нужно исследовать результаты всех прогонов. Обращайте внимание только в случае возникновения проблем.

Для случая, такого как Люпинчо:

• запуск sysdiagnoseможет выявить проблему перед перезагрузкой или выключением
• конечный результат sysdiagnose может представлять интерес следующие с принудительной перезагрузки или выключить.

Более конкретно: если пробежка sysdiagnoseне может продвинуться дальше определенной точки, знание этой точки может помочь понять основную проблему.

Во время выполнения вы можете многократно использовать следующую комбинацию клавиш, чтобы увидеть, что происходит:

• Control-T

Для allmemoryчасти sysdiagnoseрутины двухминутная оценка Apple может быть крайне неточной. Потерпи.

Если вы подозреваете, что sysdiagnoseне удается достичь определенного уровня, введите:

• Control-C

Если повторное использование Control-C не может быть прервано sysdiagnose, то (по моему опыту работы с Mountain Lion) почти наверняка произойдет сбой попытки перезапустить или завершить работу операционной системы.

Контроль выключения

В Finder перейдите по ссылке:

/private/var/log/shutdown_monitor.log

Этот файл обычно пуст, но может содержать элементы, представляющие интерес после проблемного завершения работы. (У меня мало опыта в этой области.)

Если единственный сбойный процесс при выключении - WindowServer

Нет ничего необычного в том, чтобы при отключении происходили случайные процессы. Бродяга может быть проблематичным, только если она не убита.

Если вы подозреваете, что WindowServer не уничтожен и что этот конкретный сбой способствует сбоям при завершении работы: спросите себя, использует ли какое-либо стороннее программное обеспечение нестандартное использование процесса WindowServer.

Быстрый просмотр GrabFS-представления WindowServer на Mountain Lion с двумя дисплеями:

Если Lion похож, то мое внутреннее чувство состоит в том, что причина сбоев выключения лежит за пределами WindowServer.

Догадки, основанные на результатах launchctl

Пока машина работает нормально, какова реакция на следующую команду?

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

Вам интересно, не является ли какое-либо программное обеспечение сторонних производителей причиной проблемы. Антивирус, антивирусное программное обеспечение?

После повышения от Льва до Горного Льва

Стремиться к:

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

Кажется, по умолчанию один лог на выключение, максимум два, поэтому есть также:

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

После принудительного перезапуска или принудительного выключения вы можете отложить копию самого последнего из этих двух. Если форсировка требуется более одного раза, вы можете сравнить файлы, чтобы увидеть, появляется ли шаблон.

Обычно

Не исключайте возможность проблемы со сторонним программным обеспечением, даже качество выпуска. Маленький Снитч может быть хорошо написан и широко уважаем, но:

• когда такие проблемы, как проблема в этом вопросе, становятся чрезмерными или слишком загадочными, любое расширение ядра , не относящееся к Apple, заслуживает внимания.

Я тестировал сборку 12A269 OS X 10.8 примерно за две недели до ее выпуска, уделяя особое внимание выключению в сложных ситуациях . Хотя я не смотрел ни одного видео с WWDC 2012, у меня есть ощущение, что Apple очень усердно работала, чтобы предотвратить потребность в силе во всех, кроме самых сложных ситуациях.

Опираясь на ответ Дэвида ДельМонте

По крайней мере, в «Горном льве» я вижу загрузку 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 -

Сброс контроллера системного управления (SMC) Сброс SMC на портативных компьютерах Mac с аккумулятором, который вы можете удалить

Выключи компьютер. Отключите адаптер питания MagSafe от компьютера, если он подключен. Выньте аккумулятор. Нажмите и удерживайте кнопку питания в течение 5 секунд. Отпустите кнопку питания. Подключите аккумулятор и адаптер питания MagSafe. Нажмите кнопку питания, чтобы включить компьютер.

Я не знала, что у тебя работает Маленькая Снитч. Я только что решил аналогичную проблему для друга, удалив LS. Я предлагаю вам попробовать это. Для правильного удаления снова загрузите установщик LS. Запустите установщик, но выберите «Удалить».

Мне тоже интересно, почему вы хотели бы использовать это приложение ..

Моя девушка просто удалила каталоги для параллелей, перетащив каталог в мусорное ведро и опустошив мусор. Однако я снова нашел параллели в папке «Библиотека», и был сценарий оболочки (файл .sh) для его правильного удаления. Это сработало и решило наши проблемы с долгой загрузкой.

Я упоминаю об этом, потому что параллели - известная причина многих медленных загрузок, и кажется, что удалить их не так просто, как указывает их веб-сайт (просто перетаскивая директорию).

Счастливые тропы, надеюсь, это кому-нибудь поможет.