I miejmy nadzieję, że naprawdę ostateczna edycja: po przejściu na Mountain Lion problem wydaje się naprawiony, miejmy nadzieję na stałe.

Ostateczna edycja: Problem nie pojawia się cały czas, czasem muszę czekać kilka dni, aż się pojawi. Trudno więc testować w różnych warunkach (tj. W trybie awaryjnym lub przy wyłączonym oprogramowaniu) i zdecydowałem, że nie warto spędzać dni na sprawdzaniu różnych warunków, aby to naprawić. Sugestie Grahama Perrina były najbardziej pomocne w znalezieniu konkretnych informacji na temat problemów z restartem / restartem, których nie znaleziono w dziennikach ogólnego przeznaczenia.

Niektóre wpisy dziennika znajdują się w Edytuj u dołu:

MacBook Pro z połowy 2010 roku z ekranem 15 cali i systemem OS X 10.7.4. Czasami podczas próby ponownego uruchomienia lub wyłączenia maszyny nie działa - ekran staje się szary, obraca się koło, ale maszyna nie wyłącza się, więc po kilku minutach muszę wyłączyć maszynę, naciskając zasilanie przycisk.

Nie zdarza się to za każdym razem i nie mogę powiązać żadnego oprogramowania używanego podczas sesji z problemem. W rzeczywistości, podczas testowania tego, czasami zdarza się to, gdy próbuję wyłączyć maszynę natychmiast po uruchomieniu.

Jak sprawdzić, co uniemożliwia płynne zamknięcie / ponowne uruchomienie? Zakładam, że muszę zajrzeć do niektórych plików dziennika, ale nie jestem pewien, które z nich i czego szukać.

Edycja: Dodano pełne ustawienie uruchamiania / zamykania w nvram, zgodnie z sugestią Grahama Perrina, i ostatecznie maszyna utknęła przy ponownym uruchomieniu. Widziałem kilka pełnych wpisów na ekranie i po ponownym uruchomieniu znalazłem je w /var/log/launchd-shutdown.log. Wygląda na to, że WindowServer może mieć z tym coś wspólnego. Poniżej znajduje się koniec tego pliku dziennika z usuniętymi pierwszymi 3 kolumnami (pierwsza z pewnymi rosnącymi liczbami całkowitymi, druga z wpisami „1”, a trzecia - „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).

Uzupełnianie innych odpowiedzi…

Obserwuj tryb pełny podczas ponownego uruchamiania lub zamykania

Mac OS X: Jak uruchomić w trybie pojedynczego użytkownika lub w trybie pełnym

- jeśli zaczniesz w trybie pełnym, to ponownie uruchom lub zamknij będzie podobnie pełny.

Wskazówka: jeśli wydaje się, że rzeczy w trybie pełnym nie przekraczają pewnego punktu, poczekaj może pięć minut przed:

• wymuszanie restartu (Command-Control-power); lub
• wymuszanie wyłączenia (naciśnij i przytrzymaj klawisz wyłącznika).

Jeśli wymuszony restart nie powiedzie się, może to być kolejna wskazówka na temat przyczyny problemu (ów).

Powiązane pytanie, choć nie zorientowane na problem: Czy ktoś może interpretować pełne komunikaty o wyłączeniu?

Przypadek zorientowany na problem powinien być łatwiejszy do rozwiązania dla lupincho. Mniej liści herbaty.

Aby uruchomić w trybie pełnym, bez naciskania klawisza Command-V

Preferencje mogą być przechowywane w pamięci NVRAM. Wpisz następujące polecenie w terminalu i przygotuj się na hasło administratora:

sudo nvram boot-args="-v"

Kolejne uruchomienie systemu będzie pełne.

sysdiagnose

Przed każdym ponownym uruchomieniem lub zamknięciem w terminalu:

sudo sysdiagnose

Jest to czasochłonne, ale nie musisz sprawdzać wyników wszystkich przebiegów. Zwracaj uwagę tylko wtedy, gdy pojawią się problemy.

W przypadku takim jak lupincho:

• uruchomienie sysdiagnosemoże ujawnić problem przed ponownym uruchomieniem lub zamknięciem
• końcowy wynik sysdiagnose mogą zainteresować następujące pomocą wymuszonego restartu lub wyłączenia.

Mówiąc dokładniej: jeśli seria sysdiagnosenie osiągnie określonego poziomu, znajomość tego punktu może pomóc w zrozumieniu problemu.

Podczas biegu możesz wielokrotnie używać następującej kombinacji klawiszy, aby sprawdzić, czy coś się dzieje:

• Control-T

Jeśli chodzi o allmemoryczęść sysdiagnoserutyny, dwuminutowe oszacowanie Apple może być bardzo niedokładne. Bądź cierpliwy.

Jeśli podejrzewasz, że sysdiagnosenie uda się przejść dalej niż pewien punkt, to klucz:

• Control-C

Jeśli wielokrotne użycie Control-C nie zostanie przerwane sysdiagnose, to (z mojego doświadczenia z Mountain Lion) jest prawie pewne, że próba ponownego uruchomienia lub zamknięcia systemu operacyjnego zakończy się niepowodzeniem.

Monitorowanie wyłączenia

W Finderze przejdź do:

/private/var/log/shutdown_monitor.log

Ten plik jest zwykle pusty, ale może zawierać interesujące przedmioty po problematycznym wyłączeniu. (Mam niewielkie doświadczenie w tej dziedzinie.)

Jeśli jedynym błędnym procesem podczas zamykania jest WindowServer

Nierzadko zdarzają się zbłąkane procesy podczas zamykania systemu. Zbłąkanie może być problematyczne tylko wtedy, gdy nie zostanie zabite.

Jeśli podejrzewasz, że WindowServer nie został zabity i że ta konkretna zbłąkana przyczynia się do niepowodzenia zamykania systemu: zadaj sobie pytanie, czy oprogramowanie innych firm korzysta z procesu WindowServer w niestandardowy sposób.

Szybki podgląd widoku GrabFS WindowServer na Mountain Lion, z dwoma wyświetlaczami:

Jeśli Lion jest podobny, to moje przeczucie jest takie, że przyczyną awarii zamykania nie jest WindowServer.

Zgadywanie na podstawie wyników launchctl

Gdy maszyna działa normalnie, jaka odpowiedź na następujące polecenie?

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

Zastanawiam się, czy do rozwiązania problemu przyczynia się oprogramowanie inne niż Apple. Oprogramowanie antywirusowe, anty-malware?

Po aktualizacji z Lion do Mountain Lion

Zmierzać do:

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

Wydaje się, że domyślnie jest jeden dziennik na zamknięcie, maksymalnie dwa, więc są też:

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

Po każdym wymuszonym ponownym uruchomieniu lub wymuszonym zamknięciu możesz odłożyć kopię najnowszego z nich. Jeśli wymagana jest siła przy więcej niż jednej okazji, możesz porównać pliki, aby zobaczyć, czy pojawi się wzorzec.

Ogólnie

Nie wykluczaj problemu z oprogramowaniem innych firm, nawet jakości wydania. Mały znicz może być dobrze napisany i powszechnie szanowany, ale:

• kiedy problemy takie jak to w tym pytaniu stają się zbyt duże lub zbyt zagadkowe, każde rozszerzenie jądra innego niż Apple zasługuje na uwagę.

Testowałem wersję 12A269 systemu OS X 10.8 przez około dwa tygodnie przed jego wydaniem, ze szczególnym uwzględnieniem wyłączania zachowań w trudnych sytuacjach . Chociaż nie oglądałem żadnych filmów z WWDC 2012, mam wrażenie, że Apple bardzo ciężko pracował, aby zapobiec potrzebie użycia siły we wszystkich, oprócz najtrudniejszych, sytuacjach.

Opierając się na odpowiedzi Davida DelMonte

Przynajmniej na Mountain Lion widzę ładowanie Little Snitch 3.0 Preview 2 (3857) bardzo wcześnie - przed rozpoczęciem rejestrowania zamknięcia . Jeśli rzeczy związane z tym KEXT są podobnie opóźnione w czasie zamykania , być może problem nie będzie widoczny w zwykłych plikach dziennika na dysku.

Jeśli kiedykolwiek odkryjesz przyczynę problemu - zarówno z lwem, jak i górskim - z przyjemnością się dowiem.

W międzyczasie, z wielkimi podziękowaniami za nagrodę, końcowa myśl:

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

Przejdź do Aplikacje -> Narzędzia i otwórz konsolę

Spójrz na plik system.log, być może znajdziesz tam coś.

pmset -g assertions otrzymuje podsumowanie asercji:

$ 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" 

Możesz zobaczyć ścieżkę procesu za pomocą 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

Kiedyś miałem ten problem i znalazłem poprawkę, która działała dla mnie. Chociaż nie odpowiadam bezpośrednio na twoje pytanie (jak sprawdzić, co powoduje problem), jest to poprawka, która może być warta wypróbowania:

1. Przejdź do „Macintosh HD> Biblioteka”
2. Usuń folder o nazwie „Java”
3. Opróżnić kosz
4. Zamknąć
5. Gdy uruchomisz coś związanego z Javą, zostaniesz poproszony o ponowną instalację Java, zrób to.

Następnie czas wyłączenia powinien się poprawić. Uwaga: Wciąż dostaję powolne zamykanie, gdy zamykam natychmiast po uruchomieniu systemu, więc po wykonaniu tych kroków i chęci przetestowania poczekaj kilka minut po uruchomieniu systemu, zanim nastąpi zamknięcie.

1. Czy masz podłączony sprzęt peryferyjny (USB, FW itp.)?

Jeśli tak, interesujące byłoby odłączenie wszystkiego i sprawdzenie, czy problem istnieje.

1. Czy próbowałeś naprawić uprawnienia i sprawdzić integralność pliku?

Mam nadzieję, że te pomoce.

Więcej pomysłów:

1. Utwórz kolejne konto użytkownika. Zaloguj się tylko jako konto testowe. Jeśli nie masz problemu, prawdopodobnie jest to coś w twoim oprogramowaniu użytkownika. Jeśli masz problem, możliwe, że może to być sprzęt.

2. Spróbuj odtworzyć problem, korzystając z zasilania z baterii.

3. Postępuj zgodnie z instrukcjami kontrolera zarządzania systemem Apple -

Zerowanie kontrolera zarządzania systemem (SMC) Zerowanie SMC na komputerach Mac z baterią, którą można wyjąć

Wyłącz komputer. Odłącz zasilacz MagSafe od komputera, jeśli jest podłączony. Wyjmij baterię. Naciśnij i przytrzymaj przycisk zasilania przez 5 sekund. Zwolnij przycisk zasilania. Ponownie podłącz akumulator i zasilacz MagSafe. Naciśnij przycisk zasilania, aby włączyć komputer.

Nie zdawałem sobie sprawy, że masz małego znicza. Właśnie rozwiązałem podobny problem dla znajomego, usuwając LS. Proponuję spróbować. Aby prawidłowo usunąć, pobierz ponownie instalator LS. Uruchom instalator, ale wybierz opcję odinstaluj.

Jestem też ciekawy, dlaczego chcesz korzystać z tej aplikacji ..

Moja dziewczyna po prostu usunęła katalogi z paralelami, przeciągając i upuszczając katalog do kosza i opróżniając kosz. Znalazłem jednak podobieństwa w folderze Library i istniał skrypt powłoki (plik .sh), aby poprawnie go odinstalować. To zadziałało i rozwiązało nasze problemy z długimi rozruchami.

Wspominam o tym, ponieważ podobieństwa są znaną przyczyną wielu powolnych rozruchów i wydaje się, że ich odinstalowanie nie jest tak łatwe, jak wskazuje ich strona internetowa (po prostu przeciąganie i upuszczanie katalogu).

Szczęśliwe szlaki, mam nadzieję, że to komuś pomoże.