Miesiąc 13 jest poza zakresem?

Ostatnio mój Mac wyświetla dziwne komunikaty, takie jak „Miesiąc 13 jest poza zasięgiem”.

Jak naprawić ten błąd Nie mogę udać się do autoryzowanego centrum napraw firmy Apple, ponieważ jest ono bardzo daleko od centrum Apple

Ten błąd jest z pewnością rejestrowany w iOS 11 i macOS 10.13 i nie widzę, aby powodował jakąkolwiek konkretną funkcję lub problem na dowolnej platformie.

Odniosę się tutaj do głównego pytania na temat „czy MacOS loguje się za dużo”, ponieważ jest to opinia i wrażenie, które zasługują na dyskusję. Niektóre osoby mogłyby poczuć się lepiej, gdyby nie było żadnych wiadomości, chyba że naprawdę poważny stan wymaga działania. Inni chcą jeszcze więcej szczegółów, aby mogli wiedzieć, co się dzieje / uczyć / mierzyć. Będzie to kompromis, w jaki sposób są to problemy / skategoryzowane / wykorzystane.

• Świeża instalacja systemu macOS: Console.app wyświetla błędy / usterki. Czy tego należy się spodziewać?

Ciekawym programistą, który ma kilka narzędzi, jest Howard Oakley, który bloguje na https://eclecticlight.co/

Na jego stronie pobierania znajdują się dwie interesujące aplikacje (użyj lewego linku do pobrania, ponieważ poniższe wersje produktu są w wersji beta i mogą nie być aktualne w ciągu dnia lub tygodnia):

• Consolation - alternatywna przeglądarka konsoli
• Woodpile - narzędzie do zliczania / binowania / analizy wzorców rejestrowania

Mogę zweryfikować zasadność tego problemu. Wczoraj miałem ten sam problem, a po ponownym uruchomieniu komputer stał się prawie bezużyteczny z powodu tego błędu. Z jakiegoś powodu komputer nie radzi sobie z tym miesiącem i generuje błędy wszędzie tam, gdzie są bazy danych lub listy.

Aby to naprawić:

1. Otwórz Monitor aktywności i siły rzucić dwa procesy: lsd,UserEventAgent

2. Otwórz Preferencje systemowe i przejdź do „Data i godzina”

3. Odznacz „Ustaw datę i godzinę automatycznie”

4. W kalendarzu wybierz datę sprzed grudnia 2017 r. I naciśnij Zapisz

5. Jeśli UserEventAgentlub lsdnadal powodują problemy, wymuś zamknięcie ich ponownie po ustawieniu daty.

Inni ludzie mają ten problem

Czemu?

Wydaje mi się, że UserEventAgent próbował użyć dwóch plików plist:

System/Library/LaunchAgents/com.apple.UserEventAgent-Aqua.plist

i

System/Library/LaunchAgents/com.apple.UserEventAgent-LoginWindow.plist

Podczas próby użycia listew napotkał błąd:

Month 13 is out of bounds

Nie jestem pewien, co faktycznie wydarzyło się w UserEventAgent, ale oczywiste jest, że gdy pojawia się błąd, nie może sobie z tym poradzić i powoduje wysokie zużycie procesora i pamięci RAM.

Miałem ten sam problem z ekstremalnie wysokim zużyciem procesora i pamięci przez UserEventAgent od początku grudnia 2017 r. Konsola pokazała błąd „poza zakresem”, jak opisano powyżej.

Próbowałem narzędzia pierwszej pomocy, ponownego uruchomienia komputera, trybu awaryjnego (aby wyczyścić pamięć podręczną systemu), czyszczenia pamięci NVRAM i SMD, nic nie pomogło. Zauważyłem, że użycie procesora i pamięci nie wzrosło w trybie awaryjnym.

Podobnie jak @tgray i u / kidtexas , w pewnym momencie zorientowałem się, że jeśli wyłączę wszystkie moje niestandardowe uruchamiane listy, problem nie wystąpi.

W końcu napisałem poniższy skrypt, aby pomóc mi w debugowaniu, który plist był przyczyną problemu. Skończyło się to na liście, która działa pierwszego dnia każdego miesiąca:

<key>StartCalendarInterval</key>
<dict>
    <key>Day</key>
    <integer>1</integer>
    <key>Hour</key>
    <integer>03</integer>
    <key>Minute</key>
    <integer>00</integer>
</dict>

Wiele moich list odtwarzania używa StartCalendarIntervalklucza, a korzystając ze skryptu poniżej mogę pokazać, że nie powodowały one gwałtownych problemów z pamięcią RAM i pamięcią, więc nie jest dla mnie całkowicie jasne, dlaczego jedna konkretna lista plis powoduje problem. Niezależnie od tego, jak to rozwiązałem.

Ja zdecydowanie polecam czytelnikom spojrzeć przez skrypt, aby spróbować zrozumieć, co robi, a nie tylko kopiować i wklejać. W szczególności, jak napisał to będzie działać tylko dla listy właściwości w ~/Library/LaunchAgents(nie /Library/LaunchDaemonsi inne), i to celowo tylko testuje listy właściwości, których nazwa pliku i <key>Label</key>naśladowania specyficznego wzoru: com.USERNAME.my_plist_name[.plist]. Przed uruchomieniem użyłem linijki do bootoutwszystkich moich list for plist in com."$(whoami)".*.plist; do launchctl bootout gui/"${MYUID}"/"${plist%.plist}" || true; done, a następnie zweryfikowałem, że nie pojawiają się już w launchctl listwynikach.

#! /bin/bash
# /apple/307512/month-13-is-out-of-bounds

set -euf -o pipefail

MYUID="$(id -u)"

pushd "${HOME}"/Library/LaunchAgents

while IFS= read -r -d '' plist; do
  echo "${plist}"
  stats=($(ps ux | grep -v grep | grep UserEventAgent | awk '{ print $3, $5}'))
  cpu="${stats[0]}"
  vmem="${stats[1]}"
  echo "CPU use and virtual memory size while disabled: ${stats[@]}"
  launchctl bootstrap gui/"${MYUID}" "${plist}"
  sleep 5
  stats=($(ps ux | grep -v grep | grep UserEventAgent | awk '{ print $3, $5}'))
  echo "CPU use and virtual memory size while enabled: ${stats[@]}"
  echo "Change in vmem: $(( "${vmem}" - "${stats[1]}" ))"
  echo
done < <(find . -iname "com.$(whoami).*.plist" -print0)

popd

Podobnie jak inne, miałem duże użycie procesora i ogromne zużycie pamięci RAM przez UserEventAgent (patrz mój komentarz powyżej). Zmiana daty na listopad i wymuszenie wyjścia z UserEventAgent naprawiono. Wszystko zaczęło się w sobotę po ponownym uruchomieniu komputera.

Naprawić

Zrozumiałem to dla siebie. Mam nadzieję, że dla innych z problemami to zadziała.

Problemem był list LaunchAgent, który mam w ~ / Library / LaunchAgents. Jest to prosty plik listy wywołań, który wywołuje StartCalendarInterval, który jest prawidłowym kluczem dla uruchomionych list odtwarzania. Zadanie LaunchAgent wywołuje skrypt powłoki, który kopiuje niektóre pliki do lokalizacji kopii zapasowej pierwszego dnia miesiąca. Zadanie wcale nie jest wywoływane - myślę, że jest uruchamiane, sprawdzając załadowane zadania względem kalendarza, który jest przyczyną problemu. Gdy tylko wyładowałem ten plik list i przeniosłem plik z katalogu, UserEventAgent był w porządku (po wymuszonym wyjściu). Po drugim załadowaniu plist (launchctl load xxxx), UserEventAgent zwariował.

StartCalendarInterval jest prawidłowym kluczem do uruchomienia, jak widać tutaj w dokumentach Apple .

Więc dla każdego, kto ma problemy, sprawdź katalogi LaunchAgent i poszukaj klucza StartCalendarInterval (lub dowolnego innego klucza związanego z kalendarzem). Nie miałem żadnych problemów z listami interwałowymi opartymi na czasie.

Uwaga: To nie naprawia błędów „Miesiąc 13 poza granicami”, tylko szalone zachowanie UserEventAgent.

Po zgłoszeniu tego firmie Apple i skalowaniu łańcucha eskalacji powiedziano mi, że należy to naprawić w systemie macOS 10.13.3.

Najwyraźniej jest to spowodowane tym, że aplikacja wywołuje przestarzałą procedurę NSDate „descriptionWithCalendarFormat” .

Możesz przeczytać więcej na https://forums.developer.apple.com/thread/88417 .

W niektórych przypadkach edytowanie lub usuwanie niektórych plików plist uniemożliwi programom wywołanie przestarzałej procedury, ale prawdziwą poprawką jest aktualizacja systemu operacyjnego.