Jak sprawdzić, co uniemożliwia MBP bezproblemowe wyłączenie / ponowne uruchomienie i naprawić? [Teraz z wpisami do dziennika]

12

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).
lupincho
źródło
Podłącz wszystkie normalnie używane dyski, wykonaj wszelkie normalnie używane połączenia z serwerem plików, a następnie uruchom mountkomendę. Uwzględnienie wyniku w pytaniu może pomóc zawęzić kryteria.
Graham Perrin
Nie ma normalnie używanych dysków ani połączeń z serwerem plików, podłączam dyski USB kilka razy w miesiącu, ale nie muszę teraz próbować. Uruchomiłem „mount” bez podłączonego dysku, ale nie ma nic podejrzanego.
lupincho
Proszę, która wersja Little Snitch? Czy problem można odtworzyć przy bezpiecznym rozruchu, czy bez Little Snitch?
Graham Perrin
Najnowsza stabilna LS (2.5.3), a nie podgląd wersji 3. Ale działo się tak również z poprzednimi wersjami 1-2. Nie mogę rozsądnie przetestować tego bez LS lub w trybie awaryjnym, ponieważ to nie zdarza się cały czas, czasami zajmuje to kilka dni i nie mogę obsługiwać maszyny w ten sposób przez dłuższy czas. Chyba na razie bym z tym żył i uaktualnię do Mountain Lion i zobaczę, co się stanie. Ale twoje sugestie były najbardziej pomocne i konkretne, dzięki czemu otrzymujesz nagrodę.
lupincho
Dzięki! W oparciu o plan aktualizacji systemu operacyjnego dodałem sekcję do mojej odpowiedzi. Najkrótsza odpowiedź teraz jest, że w porównaniu do 10.7.4, 10.8 powinny być zarówno (a) mniej prawdopodobne, aby wymagać siły; oraz (b) łatwiej zdiagnozować w przypadku siły.
Graham Perrin

Odpowiedzi:

6

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:

wprowadź opis zdjęcia tutaj

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
Graham Perrin
źródło
1
Dzięki, włączono tryb gadatliwy za pomocą polecenia nvram. Jednak nawet po ponownym uruchomieniu nie ma shutdown_monitor.log. Istnieją pliki launchd-shutdown.log i launchd-shutdown.log.1 (wydaje się, że tylko bieżący i 1 poprzedni z nich są przechowywane, w przeciwieństwie do innych dzienników), ale były tam wcześniej i wcześniej na nie spojrzałem. Będę sprawdzać komunikaty o wyłączeniu trybu pełnego, mam nadzieję, że widziałem, gdzie się blokuje / wyłącza.
lupincho
Jeśli problem się powtórzy, zrób zdjęcie lub dwie gadatliwości. Nie przejmuj się zbytnio skupieniem itp. Rozpoznam kluczowe punkty nawet po rozmyciu. Mam przeczucie, co jest nie tak w twoim przypadku, nowa sysdiagnoseczęść tej odpowiedzi może być najbardziej istotna.
Graham Perrin
Uwaga dodatkowa: tutaj z Mountain Lion mam /private/var/log/kernel-shutdown.log(z informacjami, które są dla mnie przydatne), ale nie /private/var/log/launchd-shutdown.log.
Graham Perrin
Dzięki za podpowiedź „sysdiagnose”, po prostu uruchom ją, poszło dobrze, spróbuję ponownie. Jak powiedziałeś, zajmuje to trochę czasu, w przeciwnym razie mógłbym umieścić go w haku wylogowania, aby uruchomić za każdym razem.
lupincho
Automatyzacja jest kusząca, ale powinienem powstrzymać się od sysdiagnosewylogowania. W skrajnym przypadku automatyzacja może pogorszyć trudną sytuację.
Graham Perrin
2

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

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

rewolwer
źródło
Nie widzę tam nic dziwnego.
lupincho
Dobra odpowiedź Revolver. +1. Czy możesz skopiować i wkleić do pytania, wpisy systemowe.log, które widzisz po zażądaniu zamknięcia - a może kilka minut wcześniej ... Wklej je do swojego pierwotnego pytania ..
David DelMonte
Przeglądałem system.log kilka razy w przeszłości i nie znalazłem nic niezwykłego w porównaniu do płynnych wyłączeń. Poczeka na następny raz, kiedy to nastąpi, i ponownie sprawdzi dzienniki. Powinienem był wyjaśnić, że znam dzienniki ogólnego przeznaczenia, zaktualizuję to w moim oryginalnym poście.
lupincho,
2

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
Lri
źródło
Uruchamiam i nic nie pokazuje. Problem polega na tym, że po zainicjowaniu zamykania / restartowania nie mogę uruchamiać żadnych poleceń. Również problem nie pojawia się zawsze, więc musiałbym to często sprawdzać lub napisać skrypt, aby zapisać informacje w pliku, aby po problematycznym wyłączeniu / ponownym uruchomieniu mógł wrócić do tego pliku i sprawdzić, czy coś się pojawiło . Ale to wydaje się dobrym punktem wyjścia, wielkie dzięki!
lupincho,
1

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.

bogdansrc
źródło
To interesujące; zrobił to, zobaczmy, co się stanie. Problem polega na tym, że nie zdarza się to za każdym razem, więc jedynym sposobem na sprawdzenie jest poczekanie kilku dni, a jeśli to się nie powtórzy, może to oznaczać, że problem został rozwiązany.
lupincho
Nie działało, po prostu wystąpił problem z wyłączaniem maszyny.
lupincho
1
  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.

David DelMonte
źródło
Zrobiłem uprawnienia do naprawy. Żadnych urządzeń peryferyjnych, nawet kabla Ethernet. Doda tę informację do pytania.
lupincho
Urządzenia peryferyjne - zawsze warto rozważyć, kiedy (jak w pytaniu Lupincho) pojawia się zapach problemu z I / O. Uprawnienia - IMHO nigdy nie zapobiegnie zamknięciu systemu operacyjnego. Dezintegracja - możliwa, ale dla mnie pytanie w obecnej formie pachnie bardziej problemami z oprogramowaniem. (Marginesie, na integralności: Jakie darmowe lub open source można używać ze sprzętem Mac w celu weryfikacji integralności każdego bloku na dysku, na którym jest używany Rdzeń bagażu? - zbyt dużo Technobabble tam w tej chwili, w końcu powinna skraplać do czegoś znacznie prościej).
Graham Perrin
1

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.

David DelMonte
źródło
Zagłosowano przede wszystkim na Twój pomysł (1). Dla pomysłu (2), z symptomami opisanymi obecnie, osobiście nie podejrzewałbym żadnej różnicy w samej mocy baterii. Jednak problemy takie jak lupincho zaskakująco trudne do zdiagnozowania bez bezpośredniego dostępu… więc nie jest to zły pomysł. Pomysł (3), problemy rozwiązane przez reset są (dla mnie) niezwykle rzadkie… ale znowu nie jest to zły pomysł - szybki i prosty do wykonania, więc i to zyskuje mój głos.
Graham Perrin
1

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 ..

David DelMonte
źródło
Jeszcze nie w pytaniu o Little Snitch po raz pierwszy wspomniano w (więcej) komentarzach do odpowiedzi.
Graham Perrin
Proszę: czy komputer twojego przyjaciela prowadził Lion, czy Mountain Lion? Która wersja Little Snitch została odinstalowana?
Graham Perrin
1
To był Lew. Nie znam wersji LS .. przepraszam.
David DelMonte,
1
Nie ma dowodów na to, że LS to powoduje i niestety, ponieważ problem nie występuje za każdym razem, testowanie tego przy usuniętym LS zajęłoby kilka dni, podczas których nie mogę stracić LS. Jeśli chodzi o powód uruchomienia LS: jest zbyt wiele programów dzwoniących do domu i to tylko kolejny poziom kontroli ruchu wychodzącego. Ostatecznie chciałbym uaktualnić do wersji 3, kiedy zostanie ona oficjalnie wydana.
lupincho
Do celów rozwiązywania problemów Little Snitch może być traktowany inaczej niż KEXT innych firm z co najmniej dwóch powodów: (i) wcześniejszego załadowania oraz (ii) umieszczenia go w domenie System pod adresem /System/Library/Extensions. Z podziękowaniami dla Davida dodałem sekcję do mojej odpowiedzi.
Graham Perrin,
0

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.

Lyra
źródło