Высокая загрузка CPU от dasd и appstoreagent по ночам в macOS 27: как исправить

Вы закрываете крышку при полностью исправном аккумуляторе, а утром Mac тёплый, вентиляторы явно поработали, и заряд упал сильнее, чем должен за ночь сна. Если всё началось сразу после обновления до macOS 27 Golden Gate, есть конкретный и хорошо задокументированный подозреваемый: два фоновых процесса, dasd и appstoreagent, застрявшие в плотном цикле, по сообщениям, каждую ночь начиная с полуночи. В этом руководстве объясняется, что это за процессы, как фоновый планировщик Apple решает, когда их запускать, как доказать, что вы столкнулись именно с этой ошибкой (а не с одной из полудюжины других причин ночного перегрева Mac), какое именно обходное решение предлагает сообщество и как его отменить, а также что мы можем и чего не можем сказать о том, исправляет ли ошибку macOS 27.0.1. Всё здесь основано на публичных сообщениях и документации; там, где что-то не подтверждено, мы так и говорим.

Ключевые выводы

• Ошибка зафиксирована, воспроизводится у нескольких пользователей, но Apple её пока не признала. В ветке на MacRumors, начатой 27 сентября, описаны скачки appstoreagent и dasd в полночь на двух MacBook, а другие участники сообщают о том же на Mac Studio и MacBook Pro. Apple не опубликовала известную проблему по этому поводу.
• Заявленная причина: задача Apple Arcade, которая никогда не переносит собственный срок. В независимых разборах говорится, что параметр ArcadePayoutResetDate в com.apple.appstored застревает в прошлом, поэтому планировщик снова и снова запускает задачу, по сообщениям, от 70 до 100 раз в секунду.
• Подтвердить это можно за две минуты, ничего не меняя. Отсортируйте процессы по CPU, прочитайте параметр и загляните в единый журнал с предикатом. Если дата в прошлом, а журнал переполнен, это ваша ошибка.
• Обходное решение сообщества: одна команда defaults write плюс killall appstoreagent. Оно переносит дату в будущее. Это обходной путь, он обратим, и, по сообщениям, работает столько, на сколько вы выбрали дату, например семь дней.
• Подтвердить, что 27.0.1 это исправляет, мы не смогли. Обновление Apple 27.0.1 (сборка 26A434) описывается как исправляющее неуказанные ошибки. Пока никто не опубликовал подтверждённого результата по этой проблеме, поэтому проверяйте на своём Mac, а не полагайтесь на догадки.
• Сначала исключите обычные причины. Индексация Spotlight и анализ Photos после обновления, Time Machine, синхронизация iCloud и настройки пробуждения для сетевого доступа тоже дают ночной нагрев, а таблица решений ниже подскажет, какое имя процесса на что указывает.

Симптом: тёплый Mac и пропавший заряд к 9 утра

Автор исходного сообщения в ветке MacRumors даёт самое чёткое описание того, как это выглядит. С момента установки macOS 27 он наблюдал скачок загрузки CPU «ровно в полночь», виновниками были appstoreagent и dasd, причём и на MacBook Pro, и на MacBook Air. Во второй раз он оставил обе машины работать на ночь с открытым iStat Menus, и в 9 утра нагрузка снова спала. Участник с Mac Studio и MacBook Pro подтвердил такое же поведение, а третий добавил полезное наблюдение: вы можете никогда не заметить нагрузку на CPU, если не запускаете системный монитор, «но вы обязательно заметите, что аккумулятор разряжается быстрее».

Несколько деталей, которые стоит различать; все они являются наблюдениями пользователей, а не документацией Apple:

• Время указывается как полночь по местному времени. Один из участников ветки говорит, что нагрузка закончилась в 9 утра. В другом разборе застрявшая метка времени описана как «сегодня в 00:00:00» в часовом поясе автора. Ни то ни другое не является документацией Apple; это наблюдения пользователей.
• Это не новшество финального релиза. Автор ветки отмечает, что люди видели это ещё в ранних бета-версиях, а китайскоязычный разбор от 24 июня описывает appstoreagent с загрузкой более 100 процентов CPU на бета-версии macOS 27 для разработчиков. То есть это давняя ошибка, которая доехала до релиза, а не свежая регрессия в релизной сборке.

Если это похоже на ваш Mac, читайте дальше. Если же нагрев у вас днём или держится несколько дней после обновления, а не только ночью, переходите к разделу о других причинах, потому что это же исправление не поможет.

Что такое dasd и appstoreagent на самом деле

Прежде чем запускать команды от незнакомцев из интернета, полезно понимать, к чему вы прикасаетесь.

appstoreagent: фоновый помощник App Store

appstoreagent — это фоновый агент уровня пользователя, входящий в механизмы App Store. Он проверяет обновления приложений, выполняет автоматические загрузки, проверяет лицензии и синхронизирует состояние App Store. Обычно он невидим и потребляет около 0 процентов CPU. Среди прочего он также ведёт учёт для Apple Arcade, и именно поэтому параметр, связанный с Arcade, оказывается в его домене (com.apple.appstored).

dasd: Duet Activity Scheduler

dasd — это демон Duet Activity Scheduler, сокращённо DAS, и один из важнейших фоновых процессов на Mac. Говард Оукли (Howard Oakley) из The Eclectic Light Company, чьи статьи являются лучшей публичной документацией по этой подсистеме, описывает его так: DAS ведёт список запланированных активностей и часто оценивает их, чтобы определить, какая должна выполняться следующей. Когда суммарная оценка активности превышает порог, DAS решает запустить её и поручает Centralized Task Scheduling, CTS, стартовать её через XPC — лёгкий механизм межпроцессного взаимодействия Apple.

Резервные копии Time Machine, очистка после обновлений ПО, проверки безопасности, проходы синхронизации и десятки обычных задач обслуживания — всё это идёт через этот конвейер. В июльском анализе 2026 года Оукли насчитал не менее 701 неидентичной активности, отправленной в DAS примерно за первую минуту после загрузки в macOS 26.5.2, и отмечает, что DAS и CTS теперь в основном отвечают за работу, выполняемую энергоэффективными ядрами на Mac с Apple silicon. Иными словами, dasd — это коммутатор. Когда он загружает CPU, это обычно означает, что кто-то подаёт ему работу или подаёт ему одну и ту же работу снова и снова.

Как планировщик принимает решения: оценки, условия и пороги

В разборе Оукли перечислены факторы, которые DAS учитывает в оценке. Среди них уровень заряда аккумулятора, подключено ли зарядное устройство, энергетический бюджет, загрузка CPU, нехватка памяти, тепловое состояние, качество сети, находится ли Mac в состоянии Power Nap и работает ли пользователь в приложении. У активностей есть собственные критерии, например «не запускать в течение 300 секунд после загрузки» для первой резервной копии Time Machine, а DAS записывает свои решения в журнал. Он показывает записи вида «Decision: Can Proceed» и «Decision: Must Not Proceed» вместе с оценкой и пороговой оценкой.

Для нашей ошибки важны два свойства этой конструкции:

1. DAS запускает работу и по сроку, и по условиям. Активность может быть помечена как подлежащая выполнению в определённое время. Если срок прошёл и условия выполнены, она запускается.
2. Активность заново регистрируется через своего владельца. После выполнения активности процесс, которому она принадлежит, здесь appstoreagent, сообщает планировщику, когда он хочет запуститься в следующий раз. Именно здесь неверная дата причиняет вред.

Идентификаторы активностей в журнале выглядят как 0:com.apple.softwareupdated.logs-cleanup:A2BBC8: идентификатор пользователя, имя активности и короткий шестнадцатеричный суффикс, который назначает DAS. Названия подсистем, которые стоит знать: com.apple.duetactivityscheduler для DAS и com.apple.xpc.activity для CTS. Первое из них вам скоро понадобится.

Заявленная причина: срок, который никогда не сдвигается вперёд

Несколько человек независимо друг от друга пришли к одному и тому же месту. Самый подробный публичный разбор — issue 82 в репозитории nix-config, где ссылаются на китайского разработчика, чей блог-пост привёл в своём ответе участник MacRumors. Его версия вкратце:

• Затронутая задача — com.apple.appstored.ArcadeResetPO, которую разбор описывает как задачу сброса выплат разработчикам Apple Arcade.
• После её выполнения параметр в домене com.apple.appstored, ArcadePayoutResetDate, должен перейти на следующий цикл. Вместо этого он остаётся зафиксированным на прошедшей метке времени.
• Поэтому dasd считает задачу просроченной и запускает её немедленно. appstoreagent заново регистрирует её с тем же истёкшим временем. Цикл повторяется примерно 70–100 раз в секунду.
• Результат: одно загруженное ядро, интенсивная запись в единый журнал, нагрев и разряд аккумулятора.

Репозиторий скрипта phobox360, написанный участником MacRumors, который говорит, что нашёл ошибку независимо, описывает тот же механизм: фоновая задача Apple Arcade под названием ArcadeResetPO раз за разом планирует саму себя в прошлом. Это двое независимых людей, пришедших к одному выводу, — больше, чем единичный случай, но всё ещё не заявление Apple.

Отдельное, более раннее сообщение от июня описывает вариант времён беты. Оно возлагает вину на ошибки базы данных в коде Arcade (отсутствующий столбец в таблице SQLite и строка журнала об обновлении уже выполняющейся задачи) и на плотный цикл запросов сетевых интерфейсов. Оно полезно в основном как свидетельство того, что проблема предшествует релизу. Его средство, заморозка процесса через kill -STOP, отключает обновления App Store на время заморозки, и сейчас люди рекомендуют не его.

Как убедиться, что это ваша проблема

Выполняйте по порядку. Ничто в этом разделе не меняет никаких настроек. Идеально выполнить первые два шага, пока Mac ведёт себя неправильно, то есть вскоре после полуночи или утром, прежде чем вы что-либо сделаете.

Шаг 1: посмотрите Мониторинг системы (Activity Monitor)

Откройте Activity Monitor из Программы > Утилиты, перейдите на вкладку CPU и отсортируйте по столбцу % CPU. Вы ищете dasd и appstoreagent одновременно в верхней части списка с устойчивой загрузкой, в идеале с большим накопленным временем CPU (CPU Time). На Mac с этой ошибкой, судя по сообщениям, занято целое ядро, поэтому значение около 100 процентов для одного процесса на многоядерной машине — это и есть признак. dasd работает от имени root, поэтому если вы видите только свои процессы, выберите «Вид > Все процессы» (View > All Processes).

Если Mac всю ночь простаивал, огромное время CPU рядом с appstoreagent — сильная подсказка даже после того, как скачок прошёл, потому что этот столбец накапливается. В июньском разборе показана строка top, где appstoreagent занимает 126,7 процента, а время работы превышает 284 минуты.

Шаг 2: подтвердите из Терминала с помощью top

Activity Monitor вполне годится, но Терминал даёт текст, который можно вставить в ветку форума. Первый замер, который печатает top, — это среднее с момента загрузки, поэтому запросите два замера и читайте второй:

top -l 2 -n 10 -o cpu -stats pid,command,cpu,time

-o cpu сортирует по CPU, -n 10 ограничивает список десятью процессами, -l 2 делает два замера, а -stats выбирает столбцы. Читайте второй блок. Если dasd и appstoreagent оба в первой же тройке-пятёрке и ни один не близок к нулю, пока Mac в остальном простаивает, это согласуется с ошибкой. В качестве более короткой альтернативы ps -axo pid,pcpu,time,comm -r | head выводит самые прожорливые по CPU процессы по текущей нагрузке.

Шаг 3: прочитайте дату Arcade

Это решающий тест, потому что он проверяет заявленную причину, а не симптом. В обсуждении проекта phobox360 указан независимый от локали способ прочитать значение. Ключ находится в домене com.apple.appstored, а значение возвращается в формате ISO 8601 при чтении через plutil:

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
defaults read com.apple.appstored ArcadePayoutResetDate
date -u +"%Y-%m-%dT%H:%M:%SZ"

Первая команда выводит сохранённую дату в виде 2026-09-26T22:00:00Z. Вторая выводит то же самое с учётом ваших региональных настроек: это легче читать, но, как выяснили авторы скрипта, на локалях с 12-часовым форматом оно может отображаться иначе, поэтому если вы собираетесь сравнивать программно, используйте первую. Третья выводит текущее время в том же формате, чтобы сравнить их на глаз.

Как это интерпретировать:

• Сохранённая дата в прошлом (раньше текущего времени UTC), пока dasd и appstoreagent заняты: это соответствует заявленной ошибке.
• Сохранённая дата в будущем, а процессы спокойны: эта ошибка — не то, что происходит у вас.
• Сохранённая дата в будущем, а процессы всё ещё заняты: происходит что-то другое, либо у цикла есть причина, которая публично не описана. Воспользуйтесь таблицей процессов ниже.
• Ключа не существует: приложение его ещё не создало, и это не свидетельствует ни за, ни против. На Mac, где никогда не запускали App Store или Apple Arcade, его может не быть.

Сохраните этот вывод до внесения любых изменений. Это ваша запись исходного значения.

Шаг 4: посмотрите единый журнал с точным предикатом

Именно в журнале можно проверить утверждение о «70–100 раз в секунду». Команда log в macOS принимает фильтр NSPredicate, а сокращённая запись process == "name" описана в man-странице log. Чтобы увидеть последние несколько минут от dasd в компактном однострочном формате:

log show --predicate 'process == "dasd"' --last 5m --style compact | head -50

Чтобы подсчитать, сколько строк было записано за одну минуту, — это грубая оценка частоты:

log show --predicate 'process == "dasd"' --last 1m --style compact | wc -l

На здоровом Mac это число скромное. Если ошибка активна, ожидайте лавину; в сообщении говорится, что цикл вызывает интенсивную запись в единый журнал. Можно также отфильтровать по подсистеме планировщика или искать имя задачи напрямую:

log show --predicate 'subsystem == "com.apple.duetactivityscheduler"' --last 2m --style compact | head -50
log show --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --last 2m --style compact | head -50

Фильтр по имени задачи самый точный. Если ArcadeResetPO встречается десятки раз в минуту, заявленная ошибка подтверждена. Чтобы наблюдать в реальном времени, а не постфактум, используйте log stream с тем же предикатом:

log stream --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --style compact

Нажмите Control-C, чтобы остановить. Два предупреждения. Во-первых, не запускайте log show на несколько часов со слишком широким предикатом на Mac с этой ошибкой, потому что журнал может быть огромным, а команда будет работать очень медленно. Держите окно коротким. Во-вторых, мы даём вам документированный синтаксис, а не стенограмму того, что будет в вашем журнале. Формулировки сообщений могут различаться между сборками, поэтому если первый фильтр пуст, попробуйте фильтр по процессу, прежде чем решать, что ошибки нет.

Шаг 5: проверьте, что не давало Mac уснуть

Если цикл работает, вы также хотите знать, был ли Mac бодрствующим во время него или просыпался ради него. Помогут два чтения pmset.

pmset -g assertions
pmset -g log | grep -E "DarkWake|Wake "

Первая показывает текущие утверждения питания (power assertions), то есть то, что сейчас мешает сну, например фоновая задача или процесс, удерживающий дисплей включённым. Вторая печатает историю пробуждений из журнала питания; у каждой строки пробуждения есть причина «due to», а DarkWake — это частичное пробуждение, при котором Mac остаётся тёмным, выполняя фоновую работу. Man-страница описывает -g log как историю засыпаний, пробуждений и других событий управления питанием, предназначенную для администраторов и отладки. Череда DarkWake на протяжении ночи, каждое из которых вызвано сетью или обслуживанием, указывает на путь планирования. Непрерывный отрезок полного пробуждения указывает на что-то, что удерживает Mac бодрствующим. Наше руководство по проблемам со сном Mac подробно разбирает чтение этих строк.

Таблица решений: какой процесс указывает на какую причину

Эта ошибка сбивает с толку потому, что полдюжины несвязанных задач тоже проявляются как фоновая нагрузка на CPU по ночам. Эта таблица сопоставляет то, что вы видите в Activity Monitor, с наиболее вероятным объяснением. Это диагностическое пособие, составленное по документации Apple и источникам, цитируемым в этой статье, а не гарантия.

Что вы видите вверху списка по CPU	Наиболее вероятная причина	Норма или проблема?	Первая проверка
dasd и appstoreagent, оба заняты, часто с полуночи	Заявленный цикл с датой Arcade	Проблема (известная по сообщениям ошибка)	Шаг 3: находится ли ArcadePayoutResetDate в прошлом?
mds, mds_stores, mdworker_shared	Индексация Spotlight	Норма в течение нескольких часов или пары дней после обновления; проблема, если никогда не успокаивается	Наше руководство по переиндексации Spotlight
photoanalysisd, mediaanalysisd	Photos сканирует вашу медиатеку (лица, сцены, объекты)	Норма после обновления или крупного импорта, особенно при подключённом питании	Откройте Photos и проверьте состояние анализа в медиатеке
backupd, backupd-helper, diskarbitrationd	Резервное копирование Time Machine	Норма раз в час; проблема, если никогда не завершается	Системные настройки > Основные > Time Machine и наше руководство по устранению неполадок Time Machine
bird, cloudd, fileproviderd	Синхронизация iCloud Drive или другого файлового провайдера	Норма при крупной синхронизации; проблема, если зациклилась	Проверьте состояние iCloud Drive и объём недавних изменений
powerd, kernel_task с высокой нагрузкой при простое	Тепловое управление или утверждение питания	По-разному; часто симптом, а не причина	Шаг 5 и список утверждений
Только dasd, память растёт до многих гигабайт	Другая проблема памяти dasd, о которой сообщалось в бета-версиях macOS 27 в стороннем блоге со ссылкой на сообщения пользователей	Проблема, но другая, и исправление с датой к ней не применимо	Вкладка «Память» в Activity Monitor
contactsd, peopled	Виджет «Контакты» и база данных истории вызовов	Известная проблема эпохи Tahoe	Наше руководство по peopled и contactsd
Стороннее приложение или его вспомогательный процесс	Само приложение	Проблема в этом приложении	Завершите его; проверьте наличие обновления

Из этой таблицы вытекают два практических правила. Во-первых, важна пара: dasd сам по себе — это планировщик, который отправляет много работы, а CPU часто тратится процессом, которому он её отправляет. dasd вместе с appstoreagent в фиксированное время — это как раз шаблон из сообщений. Во-вторых, важно время: индексация и анализ фотографий наиболее интенсивны сразу после обновления и затихают, тогда как цикл, привязанный к полуночи, должен повторяться каждую ночь.

Обходное решение сообщества, разобранное построчно

Исправление, к которому сошлись участники MacRumors и авторы разборов, — это одно изменение параметра. Вот оно в том виде, в каком опубликовано в ветке, с пояснением, которого в ветке нет.

Прежде чем что-то менять: сохраните исходное значение

Сделайте копию того, что там есть, чтобы вернуть всё обратно. Ни одна из этих команд ничего не изменяет.

defaults read com.apple.appstored ArcadePayoutResetDate > ~/Desktop/arcade-date-before.txt
defaults export com.apple.appstored ~/Desktop/appstored-before.plist

Первая записывает текущую дату в текстовый файл. Вторая экспортирует весь домен параметров com.apple.appstored в файл свойств на вашем Рабочем столе. Если первая команда печатает «does not exist», ключ отсутствует, и первую строку можно пропустить.

Команда

В том виде, как она опубликована на MacRumors и повторена в issue nix-config, версия на семь дней выглядит так:

defaults write com.apple.appstored ArcadePayoutResetDate -date "$(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ")" && killall appstoreagent

Разберём её:

• defaults write com.apple.appstored ArcadePayoutResetDate -date "..." записывает значение даты в ключ ArcadePayoutResetDate в параметрах агента App Store. Флаг -date сообщает defaults, что значение — дата, а не строка.
• $(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ") — это оболочка, вычисляющая эту дату. date -v+7d — это BSD date (тот, что в macOS), сдвигающий текущее время вперёд на семь дней, -u использует UTC, а строка формата создаёт метку времени ISO 8601 с окончанием Z. GNU date из Homebrew coreutils использует другие флаги, поэтому если вы заменили системный date в своём пути, запускайте его как /bin/date.
• && выполняет следующую часть, только если запись прошла успешно.
• killall appstoreagent завершает работающий appstoreagent, чтобы он перезапустился и прочитал новый параметр. Система снова запускает его по требованию, так что это не постоянное отключение. Если App Store посреди загрузки или обновления, это её прервёт, поэтому старайтесь делать это, когда ничего не обновляется.

Запускайте это от обычного пользователя, не через sudo. Параметр принадлежит вашей учётной записи, а проект phobox360 прямо говорит своим пользователям запускать без sudo. Запись параметров от root создала бы файл, который агент может не прочитать.

Что вы должны увидеть: через несколько секунд после перезапуска dasd и appstoreagent должны упасть почти до нуля в Activity Monitor. В разборе, где эту команду впервые задокументировали, говорится, что исправление действует немедленно. Это результат одного пользователя, а не то, что мы можем обещать для вашего Mac.

Что это меняет и чего не меняет

• Меняется одна дата. Ничего не удаляется, ни один системный файл не затрагивается, никакая защита не отключается. com.apple.appstored — обычный домен параметров уровня пользователя.
• Это не исправляет ошибку, из-за которой дата устарела. Срок отодвигается так, чтобы планировщик перестал считать задачу просроченной. Авторы сообщений описывают это как обходной путь до тех пор, пока Apple не выпустит настоящее исправление.
• Неизвестно, чтобы это влияло на вашу подписку Apple Arcade или на игры. Затронутая задача описана как сброс выплат разработчикам. Но никто не опубликовал проверку того, что происходит с учётом Arcade, когда дату переносят очень далеко. Автор скрипта говорит то же самое о более агрессивном варианте с 2035 годом. Если вы активно пользуетесь Arcade, предпочтите короткое окно в семь дней.

Выбор даты: семь дней или годы

В разборе nix-config используется 2099-01-01T00:00:00Z, что паркует задачу практически навсегда:

defaults write com.apple.appstored ArcadePayoutResetDate -date "2099-01-01T00:00:00Z"
killall appstoreagent

Это избавляет от еженедельного повторения исправления и, по сообщениям, откладывает задачу надолго «без нарушения работы App Store», но это описание принадлежит автору сообщения, а не подтверждено Apple. Дополнительный устойчивый режим скрипта phobox360 использует 2035 год и содержит явное предупреждение, что его влияние на учёт Arcade независимо не установлено. Наша рекомендация, которая является суждением, а не документированным фактом: начните с семи дней. Если это работает, вы с малым риском убедились в правильности диагноза и позже можете решить, стоит ли идти дальше.

Как отменить

Есть два пути назад, и стоит знать оба до того, как они понадобятся.

Восстановите сохранённое значение. Если вы сохранили исходную дату и она была допустимой прошедшей датой, запись её обратно возвращает прежнее состояние, которое, конечно, и есть состояние с циклом. На практике это делают только для проверки или чтобы передать чистое состояние Apple в отчёте об ошибке. Используйте строку ISO из вашего текстового файла:

defaults write com.apple.appstored ArcadePayoutResetDate -date "2026-09-26T22:00:00Z"
killall appstoreagent

Замените пример даты на вашу сохранённую.

Удалите ключ. Это убирает ваше переопределение и позволяет агенту стартовать без сохранённого значения:

defaults delete com.apple.appstored ArcadePayoutResetDate
killall appstoreagent

Удаление ключа — стандартный способ defaults вернуть настройку к значению по умолчанию. Что делает агент App Store при отсутствии ключа в macOS 27, не документировано, и он может создать заново новую, допустимую дату или ошибочную. Если цикл возвращается после удаления ключа, примените обходное решение снова.

Вариант со скриптом и насколько ему доверять

Репозиторий dasd-arcade-loop-fix оборачивает то же изменение в скрипт с пробным запуском (dry run), запросом подтверждения, автоматической резервной копией исходного значения и командой отката. На момент написания это небольшой проект почти без звёзд и форков, поэтому его широко не проверяли. Разумный вывод: прочитайте скрипт перед запуском или просто используйте однострочную команду выше, которая делает то же самое в полностью видимой форме. Если вы всё же используете скрипт, его документированные флаги — пробный запуск, откладывание на неделю по умолчанию и --rollback. Pull request исправил аварийное завершение на локалях с 12-часовым форматом, вызванное тем, как defaults read печатает даты, — хорошее напоминание о том, что shell-скрипты, разбирающие вывод параметров, хрупки.

Чего делать не следует

• Не завершайте dasd. Он принадлежит root, launchd перезапускает его сразу же, а починить планировщик, убив его, нельзя. Это к тому же не устраняет причину, по которой задача просрочена.
• Не используйте kill -STOP и не выгружайте appstoreagent как постоянную меру. Июньский разбор применил kill -STOP, потому что в бете больше ничего не помогало. Это приостанавливает процесс, поэтому обновления App Store, загрузки и проверки лицензий прекращаются, пока вы не возобновите его командой kill -CONT.
• Не отключайте защиту целостности системы (System Integrity Protection) и не редактируйте файлы в /System. Ничто из сообщений этого не требует.
• Не отключайте автоматические обновления как единственное средство и не считайте проблему решённой. Один из ответов на MacRumors предлагает это, и это может снизить частоту пробуждений агента, но не устраняет заявленную причину: задача — это сброс выплат Arcade, а не проверка обновлений. К тому же вы остаётесь без автоматических обновлений безопасности для приложений App Store. Если вы отключаете их ради проверки, включите обратно.

Почему проблема возвращается и что с этим делать

Если вы использовали команду на семь дней, записанная дата теперь настоящая, допустимая, и планировщик доволен, пока этот день не пройдёт. Когда он пройдёт, условие устаревшей даты снова возможно. Сообщения говорят, что цикл может повториться примерно через неделю. Механизм именно такой, какого можно ожидать из описания ошибки: исправление сдвигает срок, а ошибка, из-за которой он не продвигается должным образом, остаётся.

У вас два варианта.

1. Повторять команду каждую неделю. Поставьте напоминание в Календаре. Это дёшево и сохраняет состояние Arcade близким к нормальному.
2. Использовать гораздо более позднюю дату. Вариант с 2099 годом избавляет от рутины. Компромисс уже описан: менее проверенная территория для учёта Arcade.

Исправляет ли это macOS 27.0.1?

Мы не знаем, и предпочитаем сказать об этом, а не гадать.

Что можно проверить: Apple выпустила macOS 27.0.1 28 сентября. Согласно материалу The Eclectic Light Company, новый номер сборки — 26A434, обновление «по-видимому исправляет неуказанные ошибки, а также одну, связанную с Platform SingleSignOn», и публичных заметок о безопасности нет. В той статье ничего не говорится о CPU, аккумуляторе, App Store или Apple Arcade.

Что показывает ветка: после выхода 27.0.1 автор исходного сообщения написал: «Интересно, исправлено ли это теперь в macOS 27.0.1». Последовавший ответ касался другой ошибки, проблемы с разрешением локальной сети для расширений файлов, и подтверждал, что та не исправлена. Никто в ветке не сообщает результата «до и после» для цикла Arcade.

Так что честная позиция такова: это не проверено ни в ту, ни в другую сторону. Кроме того, заметьте, что расплывчатые примечания к выпуску — обычное дело, поэтому исправление может присутствовать, не будучи перечисленным.

Как выяснить это на своём Mac так, чтобы получить полезные данные:

1. Обновитесь до 27.0.1 (Системные настройки > Основные > Обновление ПО).
2. Прежде чем применять какое-либо обходное решение, выполните Шаг 3, чтобы прочитать ArcadePayoutResetDate.
3. Если вы уже применили обходное решение, дождитесь, пока пройдёт установленная вами дата, либо удалите ключ, как описано выше, и перезапустите, а затем понаблюдайте через полночь.
4. На следующее утро посмотрите top или Activity Monitor и прочитайте журнал с предикатом по имени задачи.
5. Опубликуйте результат в ветке MacRumors. Те, кто её читает, — те же люди, которым нужен ответ.

Другие причины ночного нагрева и разряда аккумулятора, которые нужно исключить

Даже если ваш dasd виновен, он может быть не один. Обновления запускают набор задач «наверстывания», и нередко одновременно существует больше одной проблемы. Пройдитесь по этим пунктам, прежде чем делать вывод, что цикл Arcade — вся история.

Индексация Spotlight и Siri после обновления

После крупного обновления macOS перестраивает части своего поискового индекса, что проявляется как mds, mds_stores и mdworker_shared. В собственных рекомендациях Apple по неожиданному пробуждению отмечено, что если Spotlight индексирует ваш диск, Mac не уснёт, а Mac, который не может уснуть, нагревается и разряжает аккумулятор за ночь. Индексация конечна: она интенсивно работает часами, на большом диске иногда день-два, затем успокаивается. Цикл Arcade не успокаивается. Наше руководство по переиндексации Spotlight после macOS 27 описывает, как отличить «ещё работает» от «застряло», а более раннее сообщение о macOS 26.6 показывает тот же шаблон с индексом Siri.

Анализ Photos

photoanalysisd и mediaanalysisd сканируют вашу медиатеку Photos в поисках людей, сцен и объектов. Они наиболее активны после обновления или импорта и завершаются; у них нет времени суток, с которого они начинаются. Оставьте Mac на ночь подключённым к питанию и посмотрите, спадёт ли нагрузка за несколько ночей.

Time Machine

Резервные копии Time Machine выполняются через тот же планировщик. В разборе Оукли показано, как DAS отклоняет резервное копирование в первые секунды после запуска, потому что активности требуется пятиминутное ожидание, — это пример работы критериев. Первая резервная копия после обновления или копия на медленное сетевое хранилище может идти часами и нагревать Mac. Если занят процесс backupd, подходящее место — руководство по устранению неполадок Time Machine, а статья Оукли о планировании и запуске резервных копий объясняет, почему копирование может стартовать в странные моменты.

Power Nap и «Пробуждение для доступа к сети»

На странице Apple о настройках сна и пробуждения сказано, что Power Nap позволяет Mac обновляться во время сна, а «Wake for network access» позволяет ему ненадолго просыпаться, чтобы другие пользователи могли обращаться к общим службам. На ноутбуке оба находятся в разделе Системные настройки > Аккумулятор > Параметры. Страница Apple о неожиданном пробуждении включает среди рекомендаций отключение пробуждения для сетевого доступа и выключение служб общего доступа. Man-страница pmset говорит, что womp — это эквивалент «Wake for network access» в Терминале, а powernap применяется на поддерживаемых машинах. Доступность Power Nap зависит от модели, так что не удивляйтесь, если не увидите его.

Чтобы проверить текущие значения, не меняя их:

pmset -g | grep -E "powernap|womp"

Отключить оба — разумный эксперимент, если ваш pmset -g log показывает регулярные DarkWake по ночам. Это не исправит цикл Arcade, который происходит, пока Mac бодрствует или проснулся для обслуживания, но уберёт шум из вашей диагностики. Вносите по одному изменению, чтобы понимать, что помогло.

Устранение типичных проблем

Процессы всё ещё заняты после команды

Симптомы: Вы выполнили defaults write и killall, но dasd и appstoreagent по-прежнему вверху Activity Monitor.

Причина: Возможно несколько вариантов. killall мог не найти процесс, поэтому старый процесс всё ещё работает со старой закэшированной датой. Запись могла молча завершиться неудачей, например из-за опечатки в домене. Либо вы наблюдаете совершенно другую причину.

Решение:

1. Прочитайте значение обратно командой plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist и убедитесь, что оно в будущем.
2. Выполните killall appstoreagent ещё раз, затем проверьте в Activity Monitor, перезапустился ли процесс с новым PID.
3. Повторите журнальный предикат по имени задачи в течение одной минуты. Если ArcadeResetPO больше не появляется, а CPU всё ещё загружен, причина в другом, и таблица процессов выше — ваша следующая остановка.

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
pgrep -l appstoreagent

Если это не помогло: Один раз перезагрузите Mac. Перезагрузка очищает кэшированные параметры и любое застрявшее состояние планировщика. Если после перезагрузки дата всё ещё допустима, а нагрузка остаётся, считайте это другой ошибкой и соберите вывод Шага 2 и Шага 4, прежде чем просить помощи.

Цикл возвращается через неделю

Симптомы: Тихая неделя, а затем ночной скачок возвращается.

Причина: Ваша дата на семь дней прошла, а основная ошибка всё ещё присутствует.

Решение: Выполните команду снова или выберите более позднюю дату, как обсуждалось выше. Если вы не хотите повторять её, выбирайте более длинное окно осознанно, помня, что его влияние на учёт Arcade не документировано.

Mac всё равно разряжается за ночь, но процессы выглядят спокойными

Симптомы: dasd и appstoreagent на нуле, а аккумулятор всё равно падает.

Причина: Нагрев и разряд во время сна часто вызваны пробуждениями и утверждениями питания, а не CPU.

Решение: Прочитайте pmset -g log за ночной промежуток и посмотрите, как часто Mac просыпался и почему. Проверьте pmset -g assertions на предмет того, что мешает сну. Наше руководство по проблемам со сном Mac и руководство по разряду аккумулятора в macOS Tahoe разбирают типичных виновников, а руководство по расширенной диагностике аккумулятора подробнее описывает чтение данных об аккумуляторе.

FAQ

Почему dasd и appstoreagent так сильно загружают CPU в macOS 27?

По сообщениям участников MacRumors и независимым разборам, задача Apple Arcade ArcadeResetPO хранит дату в прошлом, поэтому планировщик постоянно перезапускает её, возможно, 70–100 раз в секунду. Apple этого не подтвердила. Шаблон такой: одно загруженное ядро, часто с полуночи, с нагревом и более быстрым разрядом аккумулятора.

Безопасно ли выполнять команду defaults write для ArcadePayoutResetDate?

Она меняет один параметр уровня пользователя и не затрагивает системные файлы, а отменить её можно удалением ключа или восстановлением сохранённого значения. Это обходное решение сообщества, а не рекомендация Apple, и его долгосрочное влияние на учёт Arcade не документировано. Сначала сохраните исходное значение и предпочтите короткое окно.

Исправляет ли macOS 27.0.1 цикл dasd и appstoreagent?

Подтвердить это мы не смогли. Обновление Apple 27.0.1, сборка 26A434, по сообщениям, исправляет неуказанные ошибки и одну проблему Platform SSO, без упоминания этой. Единственное сообщение на MacRumors с таким вопросом получило ответ о другой ошибке. Проверьте на своём Mac, прочитав дату через полночь.

Как понять, что это именно эта ошибка, а не Spotlight или Photos?

Прочитайте сохранённую дату через plutil и сравните с текущим временем UTC. Если она в прошлом, пока dasd и appstoreagent заняты, а журнал показывает повторяющуюся задачу ArcadeResetPO, это эта ошибка. Spotlight проявляется как процессы mds, а Photos как photoanalysisd, без фиксированного старта в полночь.

Почему проблема возвращается через неделю?

Обходное решение переносит дату сброса на неделю вперёд. Когда эта дата проходит, основная ошибка, из-за которой она не продвигается, может проявиться снова, и цикл возвращается. Авторы сообщений описывают повторение примерно через неделю. Можно повторять команду каждую неделю или выбрать более позднюю дату, принимая, что длинные даты менее проверены.

Остановит ли это отключение автоматических обновлений App Store?

Один из ответов на MacRumors говорит, что процессы затихают, но это не устраняет заявленную причину, то есть задачу выплат Arcade, а не проверку обновлений. Это также означает, что вы перестаёте получать автоматические обновления приложений App Store. Считайте это компромиссом, который стоит проверить, а не исправлением, и включите обновления обратно, если не помогло.

Можно ли просто завершить dasd или appstoreagent?

Завершение appstoreagent ненадолго останавливает скачок, но система перезапускает его по требованию, а устаревшая дата остаётся, поэтому цикл возобновляется. dasd — планировщик под управлением root, который launchd перезапускает сразу же. Заморозка appstoreagent через kill -STOP работает, но останавливает обновления App Store и проверки лицензий, пока вы не возобновите процесс.

Повлияет ли исправление на мои игры или подписку Apple Arcade?

В публичных сообщениях ничего такого не говорится. Задача описана как сброс выплат разработчикам, а обходное решение меняет только одну дату. Но никто не опубликовал проверку переноса на годы вперёд, а автор скрипта прямо говорит, что влияние на учёт Arcade не установлено. Если вы играете в Arcade, используйте короткое окно.

Заключение

Шаблон, стоящий за Mac, который горячий и разряженный по ночам в macOS 27, во всё большем числе сообщений — это цикл планировщика: dasd отправляет, а appstoreagent заново регистрирует задачу Apple Arcade, дата которой никогда не сдвигается вперёд. Подтвердить это дёшево и без изменений: прочитайте сохранённую дату, сравните её с UTC и найдите имя задачи в журнале. Если дата в прошлом, однострочное обходное решение сообщества, по сообщениям, немедленно останавливает цикл, и его легко отменить.

Сохраняйте трезвые ожидания. Это обходной путь, который придётся повторять, если вы не согласитесь на более далёкую дату, Apple ошибку не признала, и мы не можем сказать, что 27.0.1 или любое последующее обновление её исправляет. Если проверка даты оказалась чистой, не натягивайте диагноз; проработайте Spotlight, Photos, Time Machine, iCloud и настройки пробуждения по одному, используя таблицу решений выше.

Для более глубокого изучения наше руководство по переиндексации Spotlight описывает самую частую законную причину горячего Mac после обновления, а руководство по проблемам со сном Mac — проблемы пробуждений и утверждений питания. Если виновник — другой процесс, ему может соответствовать руководство по peopled и contactsd. И если вы выясните, изменило ли что-нибудь 27.0.1 на вашем Mac, сообщите об этом участникам ветки MacRumors.

Есть вопросы или советы? Мы будем рады узнать о вашем опыте в комментариях ниже.

Читайте также: Переиндексация Spotlight после macOS 27, Mac горячий и разряжает аккумулятор после macOS 26.6, Полное руководство по исправлению разряда аккумулятора в macOS Tahoe, Руководство по обновлению в день выхода macOS 27 Golden Gate