І, сподіваємось, справді остаточне редагування: Після оновлення до Гірського Лева питання видається виправленим, сподіваємось, назавжди.

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

Деякі записи журналу є в Редагуванні внизу:

Середина 2010 року 15in 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); або
• примусове вимкнення (натисніть і утримуйте клавішу живлення).

Якщо примусовий перезапуск не вдається, це може бути ще однією підказкою до причини проблем.

Питання, пов’язані з цим, хоч і не орієнтоване на проблеми: чи може хтось інтерпретувати повідомлення про відключення багатослівного перегляду?

Проблемно-орієнтований випадок тут повинен бути легше вирішити для лупінчо. Менше листя чаю.

Запуск у багатослівному режимі без клавіші Command-V

Налаштування можна зберігати в NVRAM. Введіть таку команду в термінал і будьте готові ввести пароль свого адміністратора:

sudo nvram boot-args="-v"

Наступним запуском системи буде багатослівний.

системдіагноз

Перед кожним перезавантаженням або відключенням у Terminal:

sudo sysdiagnose

Це забирає багато часу, але вам не потрібно досліджувати результати всіх пробіжок. Зверніть увагу лише в тому випадку, якщо виникають проблеми.

Для такого випадку, як люпінчо:

• Запуск sysdiagnoseможе виявити проблему перед перезапуском або вимкненням
• кінцевий результат sysdiagnose може становити інтерес такі з примусовою перезавантаження або вимкнути.

Більш конкретно: якщо пробіг sysdiagnoseне просувається за межі певної точки, знаючи, що ця точка може допомогти отримати розуміння основної проблеми.

Під час запуску ви можете неодноразово використовувати таку комбінацію клавіш, щоб побачити, чи все прогресує:

• Контроль-Т

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

Якщо ви підозрюєте, що sysdiagnoseне вдалося досягти певного моменту, тоді введіть:

• Контроль-С

Якщо багаторазове використання Control-C не вдасться перервати sysdiagnose, то (на моєму досвіді з Mountain Lion), майже впевнено, що спроба перезапустити або вимкнути операційну систему не вдасться.

Моніторинг вимкнення

У Finder перейдіть до:

/private/var/log/shutdown_monitor.log

Цей файл, як правило, порожній, але може містити цікаві предмети після проблемного вимкнення. (У мене мало досвіду в цій галузі.)

Якщо єдиним бродячим процесом при відключенні є WindowServer

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

Якщо ви підозрюєте, що WindowServer не загинув і що цей конкретний бродяг сприяє відмові відключення: запитайте себе, чи використовує якесь програмне забезпечення сторонніх виробників нестандартне використання процесу WindowServer.

Швидкий огляд GrabFS WindowServer на гірському Леві з двома дисплеями:

Якщо Лев схожий, то моє відчуття кишки полягає в тому, що причина збоїв у відключенні криється за межами WindowServer.

Відгадування, засноване на результатах startctl

Поки машина працює нормально, яка відповідь на наступну команду?

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

Поцікавтеся, чи якесь програмне забезпечення, яке не належить Apple, сприяє цій проблемі. Противірусне, анти-шкідливе програмне забезпечення?

Після оновлення від Лева до Гірського Лева

Мета:

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

Здається, за замовчуванням - один журнал на вимкнення, максимум два, тому також є:

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

Після будь-якого примусового перезапуску або примусового вимкнення ви можете обрати копію останньої з двох. Якщо потрібна сила з будь-якого випадку, ви можете порівняти файли, щоб побачити, чи з’являється візерунок.

Взагалі

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

• коли такі проблеми, як ця у цьому питанні, стають розширеними або занадто неприємними, будь -яке розширення ядра, яке не належить Apple, заслуговує на увагу.

Я протестував Build 12A269 OS X 10.8 протягом двох тижнів, перш ніж його випустити, з особливою увагою до припинення поведінки у складних ситуаціях . Поки я не дивився жодного відео з 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> Library"
2. Видаліть папку під назвою "Java"
3. Порожній кошик
4. Закрити
5. Щойно ви запускаєте що-небудь, пов’язане з Java, вам буде запропоновано перевстановити Java, зробіть це.

Після цього час відключення має покращитися. Примітка. У мене все ще відбувається повільне вимкнення, коли я вимикаюсь одразу після запуску системи, тому, виконуючи кроки та хочете перевірити, зачекайте кілька хвилин після запуску системи, перш ніж вимикатися.

1. Чи підключено периферійне обладнання (USB, FW тощо)?

Якщо так, то було б цікаво відключити все і подивитися, чи існує проблема.

1. Ви спробували відремонтувати дозволи та перевірити цілісність файлів?

Сподіваюся, ці допоможуть.

Ще кілька ідей:

1. Створіть інший обліковий запис користувача. Увійдіть лише як цей тестовий рахунок. Якщо у вас немає проблеми, можливо, це є щось у вашому користувальницькому програмному забезпеченні. Якщо у вас є проблеми, можливо, це може бути обладнання.

2. Спробуйте відновити проблему лише за допомогою живлення акумулятора.

3. Виконайте кроки для контролера управління системою Apple -

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

Вимкніть комп’ютер. Від'єднайте адаптер живлення MagSafe від комп'ютера, якщо він підключений. Вийміть акумулятор. Натисніть та утримуйте кнопку живлення протягом 5 секунд. Відпустіть кнопку живлення. Підключіть акумулятор та адаптер живлення MagSafe. Натисніть кнопку живлення, щоб увімкнути комп'ютер.

Я не здогадувався, що у тебе працює Маленький Сніт. Я просто вирішив подібне питання для товариша, видаливши Л.С. Я пропоную вам спробувати це. Щоб правильно видалити, знову завантажте інсталятор LS. Запустіть інсталятор, але виберіть видалення.

Мені теж цікаво, чому ви хочете використовувати цей додаток ..

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

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

Щасливі стежки, сподіваюся, що це комусь допоможе.