Перейти к основному содержимому

Диагностика

Здесь собраны проблемы, с которыми операторы майнеров сталкиваются чаще всего: как каждая выглядит снаружи и какая команда или строка лога говорит, что на самом деле сломалось. Референсный клиент разделён на фоновый демон и CLI, который общается с ним через локальный сокет, поэтому почти любая диагностика начинается одинаково: спросить у демона, что он думает о собственном состоянии, а затем прочитать лог. Установка и настройка клиента описаны в статьях Установка и Конфигурация.

Первые три команды​

Прежде чем копать конкретный симптом, выполните:

aetron-miner status
aetron-miner daemon status
aetron-miner engine status

status печатает путь к конфигу, PID и аптайм демона, настроенную сеть, реально используемый бэкенд цепи, состояние майнинга, GPU, память, уровень Pulse, бэкенд инференса и размер кэша. daemon status сообщает о pid-файле, пути к сокету и о том, проходит ли RPC-пинг. engine status показывает jobs_completed, jobs_failed, avg_latency_ms, last_error и счётчики Pulse. Вместе они отделяют «процесс мёртв» от «процесс жив, но ничего не делает».

Демон пишет лог в ~/.aetron-miner/daemon.log. Стримить его можно командой aetron-miner logs. Если файла нет, значит демон логирует в stderr, и вам нужно перенаправить вывод самостоятельно или запускать его под супервизором вроде systemd.

Демон не стартует​

aetron-miner daemon start порождает отсоединённый демон и ждёт появления pid-файла и сокета. Если ни то, ни другое не появилось вовремя, команда падает с daemon failed to start within <timeout>. Check ~/.aetron-miner/daemon.log. Это означает, что процесс запустился и умер, поэтому ответ лежит в логе, а не в выводе CLI.

Что проверить по порядку:

  • Бинарь не найден. aetron-miner-daemon binary not found означает, что CLI не нашёл демон ни рядом с собой, ни в PATH. Положите оба бинаря в один каталог.
  • Нет конфига. Если status печатает config: missing (...) - run \aetron-miner init``, демону нечего загружать. Запустите мастер init.
  • Зависший процесс. daemon already running с PID означает, что живой pid-файл существует. Используйте aetron-miner daemon restart, а не запускайте второй экземпляр.
  • Неверно настроен релизный раннер. Если подписанный релизный раннер настроен, но путь не существует, демон завершается, а не откатывается молча на путь разработки. В логе будет сказано, что бинарь настроен, но не найден, с указанием пути из AETRON_RUNNER_BINARY или runner_binary в конфиге. Это намеренное поведение с отказом в закрытую: молчаливое понижение позволило бы атакующему протащить подменённый бинарь мимо проверки подписи.

Если daemon status говорит RPC: socket exists but daemon not responding (probably dying), значит файл сокета пережил процесс. Выполните aetron-miner daemon stop (он его удалит) и запустите снова.

GPU не определяется​

Симптом такой: status показывает бэкенд инференса CPU или уровень Pulse сильно ниже возможностей железа, хотя GPU на машине очевидно есть. Почти всегда причин две.

Песочница против CUDA. Песочница демона на Linux блокирует исходящий сетевой трафик на уровне системных вызовов. Слишком широкий фильтр, отказывающий каждому вызову socket(), заодно мешает драйверу CUDA перечислить GPU, что всплывает в логе раннера как Error 304 (cudaErrorOSCall) вместе с torch.cuda.is_available()=False. Дальше работа тихо продолжается на CPU. Это чинилось сужением фильтра до интернет-семейств адресов, поэтому если вы видите эти две строки вместе, у вас старая сборка. Раннер печатает выбранное устройство как device=, и это самый быстрый способ узнать, что он реально выбрал.

Драйвер против сборки. Бандл раннера, собранный под более новую мажорную версию CUDA, откатывается на CPU на хосте со старым драйвером. Метка уровня берётся из nvidia-smi и всё равно будет выглядеть правильной, поэтому доверяйте device= в логе раннера, а не метке уровня.

Работа на CPU там, где задача ждёт класс GPU, - это не просто медленно. Результаты, посчитанные на неожиданной архитектуре, с большей вероятностью не пройдут проверку, поэтому неправильный device= считайте настоящей проблемой, а не вопросом производительности.

Майнер не доходит до ноды​

Клиент честно говорит об этом, а не притворяется. Поле chain в aetron-miner status показывает одно из трёх: настоящее соединение, симуляцию по замыслу или откат с указанием причины. Если это откат, строка причины говорит, какой шаг сломался:

  • AETRON_WALLET_PASSWORD not set: демон не может разблокировать хранилище, поэтому подписывать нечем. Задайте переменную в окружении демона.
  • keystore unlock failed: ...: неверный пароль либо файл хранилища отсутствует, повреждён или записан неподдерживаемой версией. aetron-miner wallet info покажет, какое хранилище читается.
  • connect failed: ...: URL ноды недоступен или соединение отклонено. Проверьте URL в конфиге и то, что нода принимает WebSocket RPC.
  • register failed: ...: соединение поднялось, а регистрация нет, поэтому сдачи работы будут отбиваться пальетой. Проверьте настроенные идентификаторы Нейронета и задачи и баланс аккаунта.

Симулированный бэкенд появляется только тогда, когда конфигурация просит об этом. Обе публичные сети работают на рантайме PoI, поэтому testnet и mainnet подключаются по-настоящему, а неудача подключения оставляет майнера офлайновым, а не уводит в тихую симуляцию. Если вы видите симулированный бэкенд, ничего такого не настраивая, у вас старая сборка. Что задеплоено, описано в Статусе проекта.

Пиры не находятся​

Обнаружение пиров работает через DHT, которой нужна хотя бы одна точка входа. Стартовый лог явно предупреждает, когда стартовать не от чего: без seed для DHT и с пустым кэшем пиров майнер никогда не попадёт в чужую таблицу маршрутизации, а шлюз не сможет разрешить его адрес. Задайте AETRON_BOOTSTRAP_ADDRS одним или несколькими мультиадресами.

Типичные ошибки:

  • Seed-адрес без peer ID. Лог предупредит, что адрес без /p2p/<peer_id> пропущен. Мультиадреса для bootstrap обязаны нести peer ID.
  • NAT без relay. Отдельное предупреждение срабатывает, когда AETRON_RELAY_ADDRS пуст: майнер за NAT недоступен без резервации на relay, даже если его собственные исходящие соединения работают.
  • Кэш пиров отключён или недоступен для записи. Кэш позволяет перезапущенному майнеру вернуться без seed-адресов. Его путь берётся из AETRON_PEER_CACHE_PATH, а пустое значение выключает кэш.

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

Модель не скачивается или не проходит проверку​

Загрузки идут через демон, а не через CLI, поэтому aetron-miner models download --from <url> сразу падает с сообщением о необходимости запустить демон, если тот не поднят. Демон забирает manifest.json с базового URL и сверяет каждый файл против него, прежде чем что-либо опубликовать в кэш.

Загрузка падает в закрытую в нескольких точках, и ошибка называет сработавшую проверку:

  • Файл, чей sha256 не совпал с манифестом, обрывает всю загрузку.
  • Файл, чей размер не совпал с манифестом, отклоняется точно так же.
  • Ответ не из диапазона 2xx сообщает HTTP-статус вместе с URL, который его вернул.
  • Запись манифеста с подозрительным путём или хэшем артефакта отклоняется сразу как попытка выхода за пределы каталога.
  • Слишком большой manifest.json отклоняется, а не разбирается, чтобы не словить нехватку памяти.
  • Когда вы передаёте --model-hash, корень Меркла, посчитанный по файлам манифеста, обязан совпасть с ожидаемым хэшем модели из цепи. Расхождение отклоняет загрузку, и это то, что не даёт поддельному зеркалу отдать подменённые веса.
  • Повторная загрузка уже закэшированного артефакта отклоняется. Сначала удалите его.

Чтобы посмотреть, что уже лежит на диске, используйте aetron-miner models list: он показывает статус каждого артефакта. Corrupt идёт с причиной, Partial означает прерванную загрузку с числом полученных байт, ManifestOnly - метаданные без самих байт, а MissingManifest - файлы, которые не с чем сверять. aetron-miner models verify <prefix> по умолчанию делает проверку метаданных, а --full пересчитывает хэши всех файлов манифеста и сообщает каждый несовпавший путь. Префикс хэша должен быть не короче 6 шестнадцатеричных символов, а неоднозначный префикс сообщается вместе со списком подошедших артефактов.

Задания не приходят​

Если демон поднят, а engine status показывает jobs_completed, застрявший на нуле, идите по этому порядку.

  1. А движок вообще запущен? aetron-miner daemon start поднимает только демон. aetron-miner start поднимает демон, а затем движок. Проверьте режим в engine status и то, что движок не на паузе.
  2. Прочитайте last_error. Снимок движка несёт последний сбой, который он видел, и обычно там названа сломавшаяся стадия.
  3. Проверьте бэкенд цепи. Симулированный бэкенд означает, что регистрация не дошла до настоящей сети, поэтому реальных задач вам не пришлют никогда.
  4. Проверьте обнаружение. Если ваш адрес никто не может разрешить, запросы не придут, каким бы здоровым ни был локальный процесс. См. раздел про пиров выше.
  5. Проверьте jobs_failed. Задания, которые приходят и падают, - это другая проблема, чем задания, которые не приходят вовсе, и обычно она указывает на раннер, а не на сеть.

Смежный сценарий связан с циклом Pulse, а не с циклом заданий. У быстрых стадий Pulse таймаут 15 секунд, у стадии доказательства - 60. Если memory-hard таблицу Pulse не удаётся построить в пределах быстрого таймаута на уровне с большой памятью, демон решает, что раннер завис, перезапускает его, и движок уходит в состояние ошибки, повторяя этот круг. Признак - повторяющиеся таймауты Pulse в логе при том, что движок так и не выходит на стабильный режим.

Вердикты расходятся​

Вердикт проверки - это двоичный Match или Mismatch, который проверяющий сначала коммитит, а затем раскрывает. Расхождения иногда случаются, и это заложено в конструкцию: судьбу майнера решает кворум независимо набранных проверяющих, а не какое-то одно сравнение, и сейчас рантайм настроен на кворум 20 с порогом 10, поэтому вердикт о мошенничестве требует расхождения минимум у половины кворума. Одно случайное расхождение против вас ничего не решает.

Если ваши собственные проверки регулярно расходятся с остальным кворумом, причина обычно локальная, а не протокольная:

  • Не то устройство. Работа, откатившаяся на CPU, даёт результаты с архитектуры, отличной от заявленной, что выносит сравнение за откалиброванный допуск. Проверьте device= в логе раннера.
  • Не та модель или точность. Проверка сравнивает с параметрами исполнения, объявленными задачей. Обслуживание в другом квантовании или другой точности проверку не пройдёт. См. Спецификацию исполнения.
  • Устаревший или неполный кэш модели. Прогоните aetron-miner models verify <prefix> --full по модели, которую использует задача.
  • Дрейф окружения раннера. Раннер без нужного модуля или с несовпадающей версией библиотеки падает так, что это выглядит расхождением, а не крахом. Сначала выполните aetron-miner env verify, потом читайте лог раннера: не проходящий самотест объясняет сразу целый класс расхождений.

Что именно меряет сравнение и почему межархитектурные результаты сравниваются с допуском, а не на побитовое равенство, разобрано в статьях Проверка инференса и Гетерогенный майнинг.

Последнее обновление