Місяць 13 поза межами?


23

Останнім часом на моєму Mac з'являються дивні повідомлення, такі як "13 місяць поза межами".

введіть тут опис зображення

Як виправити цю помилку, я не можу звернутися до авторизованого центру ремонту яблук, оскільки він знаходиться дуже далеко від центру Apple


Від @tgray: "Я почав отримувати високе використання процесора сьогодні через UserEventAgent. Він також використовує величезну кількість оперативної пам’яті (30+ ГБ, якщо я дозволяю йому працювати досить довго). Сила виходу з системи та перезавантаження нічого не змінила. Я зробив зразок процес і побачив тону рядків, що стосуються дат. Коли я змінив дату на листопад, моє використання процесора повернулося до нормального. Друге, що я змінив його до теперішнього, він знову завис. Цікаво, чи це пов’язано з датою iOS помилка в 11.2.1? Я сподіваюся, що Apple виправить це незабаром, оскільки мій комп'ютер непридатний ".
JMY1000

Відповіді:


10

Ця помилка реєструється на iOS 11 та на macOS 10.13 точно, і я не бачу, що це спричиняє якусь конкретну функцію чи проблему на будь-якій платформі.

Я посилаюсь на головне запитання про те, "чи macOS заносить занадто багато", оскільки це думка та враження, які варті обговорення. Деякі люди можуть почувати себе краще, якби не було повідомлень, якщо дійсно серйозний стан не потребує дій. Інші хочуть ще більше деталей, щоб вони могли знати, що відбувається / вчитися / вимірювати. Отже, це буде компромісом, як це питання / класифіковані / використовувані.

Один цікавий розробник, який має деякі інструменти, - Говард Оклі, який веде блоги за адресою https://eclecticlight.co/

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

  • Consolation - альтернативний консольний браузер
  • Woodpile - інструмент для підрахунку / бункера / аналізу моделей лісозаготівлі

10

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

Щоб виправити це:

  1. Open Activity Monitor і сили кинути два процеси: lsd,UserEventAgent

  2. Відкрийте Налаштування системи та перейдіть до "Дата та час"

  3. Зніміть прапорець "Установити дату та час автоматично"

  4. У календарі виберіть дату до грудня 2017 року та натисніть Зберегти

  5. Якщо проблеми UserEventAgentчи lsdнадалі виникають, примушуйте їх кинути їх знову після встановлення дати.

Інші люди мають цю проблему

Чому?

Мені здається, UserEventAgent намагався використовувати два файли плістів:

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

і

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

Коли він намагався використовувати плісти, сталася помилка:

Month 13 is out of bounds

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


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

@qwerty Ви все ще отримуєте помилку, незважаючи на встановлення дати та часу до грудня 2017 року? В ідеалі встановіть дату та час на 1 листопада, а потім вбийте згадані вище процеси за допомогою монітора активності.
Ckacmaster

Я навіть раніше це пробував. Я також спробував змінити його на 1 січня, але він все ще не працює. Я думаю, що я повинен просто ігнорувати цю помилку, оскільки у мене немає високого використання процесора або оперативної пам'яті. Я сподіваюся, що Apple виправить це в наступному оновлення програмного забезпечення. Ну принаймні це краще, ніж коренева помилка: macrumors.com/how-to/temporary-fix-macos-high-sierra-root-bug
ніхто не користувач

(Я не можу додати коментар, вибачте.) Я почав отримувати високе використання процесора сьогодні через UserEventAgent. Він також використовує величезну кількість оперативної пам’яті (30+ ГБ, якщо я дозволяю їй працювати досить довго). Сила виходу з ладу та перезавантаження нічого не змінила. Я зробив зразок процесу і побачив тону рядків, що стосуються дат. Коли я змінив дату на листопад, моє використання процесора повернулося до нормального. Другий я змінив його до теперішнього, він знову пішов на бокси. Цікаво, чи пов’язано це з помилкою дати iOS в 11.2.1? Я сподіваюся, що Apple виправить це незабаром, оскільки мій комп'ютер непридатний.
hmode

1
@qwerty Не дозволяйте комп'ютеру взагалі вимикатись, поки Apple не виправить це. Я зробив помилку перезавантаження, коли вперше побачив помилку на консолі XCode, і моє використання оперативної пам’яті та процесора стало погіршенням гірше. Після деякого розслідування я зрозумів, що буду робити вищезазначене для тимчасового рішення, як мій комп'ютер була майже марною. Помилка в основному нешкідлива, якщо ви не перезавантажите або не спробуєте завантажити будь-які файли плістів.
Ckacmaster

2

У мене була така ж проблема з надзвичайно високим процесором UserEventAgent і використанням пам'яті, починаючи з початку грудня 2017 року. Консоль показала помилку "місяць поза межами", як описано вище.

Я спробував утиліту диска "перша допомога", перезавантажився, безпечний режим (для очищення кеш-системи), очищення NVRAM та SMD, нічого не допомогло. Я помітив, що використання процесора та пам'яті не сприймалося в безпечному режимі.

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

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

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

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

Я настійно рекомендую читачам переглянути сценарій, щоб спробувати зрозуміти, що він робить, а не просто скопіювати та вставити. В Зокрема, як написано це буде працювати тільки для plists в ~/Library/LaunchAgents(НЕ /Library/LaunchDaemonsта інших), і він навмисно перевіряє тільки plists чийого імені файлу і <key>Label</key>слідувати шаблоном конкретного: com.USERNAME.my_plist_name[.plist]. Перш ніж запустити його, я застосував один-лайнер для bootoutвсіх своїх списків:, for plist in com."$(whoami)".*.plist; do launchctl bootout gui/"${MYUID}"/"${plist%.plist}" || true; doneа потім перевірив, що вони більше не з’являються під launchctl listрезультатами.

#! /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

Зауважте людям, які працюють на цьому: воно передбачає, що всі агенти, які він тестує, вже вимкнено, тому слід уважно запустити bootout(або подібне), що рекомендує n8henrie.
Кен Вільямс

1

Як і інші, я мав високе використання процесора та величезне використання оперативної пам’яті від UserEventAgent (див. Мій коментар вище). Змінюючи дату на листопад і примушуйте виходити з фіксованих речей UserEventAgent. Все почалося в суботу після того, як я перезавантажився.

Виправити

Я зрозумів це для мене. Сподіваємось, що для інших із проблемами це буде працювати для вас.

Проблема полягала в списку LaunchAgent, який я маю в ~ / Бібліотеці / LaunchAgents. Це простий файл-пліст, який викликає StartCalendarInterval, який є дійсним ключем для запущених плістів. Завдання LaunchAgent викликає скрипт оболонки, який копіює деякі файли в резервне місце в перший день місяця. Робота взагалі не викликається - я думаю, що вона запускається з перевірки завантажених завдань на Календар, який викликає проблему. Як тільки я вивантажив цей пліст і перемістив файл із каталогу, UserEventAgent був добре (після виходу з сили). Другий я завантажив пліст (startctl load xxxx), UserEventAgent пішов нанівець.

StartCalendarInterval є дійсним ключем для запуску, як це бачимо в документах Apple .

Тому для тих, хто має проблеми, перевірте свої каталоги LaunchAgent і шукайте ключ StartCalendarInterval (або будь-який інший пов’язаний з календарем ключ). У мене не було жодних проблем із часовими інтервалами списків.

Примітка. Це не виправляє помилки "Місяць 13 поза межами", а лише шалена поведінка UserEventAgent.


Насправді я не маю високого використання процесорного агента User Event Agent. Також я не маю високого використання ZCPU та RAM.
ніхто не користувач

Ця відповідь мені допомогла. Хоча у мене не було проблем з UserEventAgent, але lsd зійшов з розуму. На щастя, я пам'ятаю, що я створив пліст із StartCalendarEvent власноруч. Просто відключив його і насильно вбив lsd.
Денис Грозний

0

Повідомляючи про це Apple і масштабуючи ланцюг ескалації, мені сказали, що це слід виправити в macOS 10.13.3.

Мабуть, це викликано програмою, яка викликає застарілу процедуру NSDate 'descriptionWithCalendarFormat' .

Детальніше ви можете прочитати на https://forums.developer.apple.com/thread/88417 .

У деяких випадках редагування або видалення певних файлів плістів не дозволить програмам викликати застарілу процедуру, але справжнє виправлення - це оновлення ОС.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.