Есть такое устойчивое выражение
"дело было не в бобине"
Описывает ситуацию, когда проблема была в другом.
- - -
Сидел вечером, ковырял документацию, чтобы догнать коллег по знаниям AI.
А то стал сильно отставать от них.
Курсор предлагает обновится, я соглашаюсь - ну а чо, вечер, казалось бы, что я могу поломать?
Он обновляется и тут ноут включает режим вертолёта: кулеры на взлёт, корпус тёплый, курсор дёргается.
M5, прости господи, топовое железо планеты, а ведёт себя так, будто я ему майнинг ферму на коленке запустил.
Ну, лезу в htop руками: кто это мне нагружает цпу сейчас.
clang processes: 73, summed %CPU: 778.3
(кто такие кланг? я вообще не в курсе)
Семьдесят три процесса clang и почти 800% CPU. То есть кто-то прямо сейчас яростно компилирует C++ всеми ядрами сразу. На моей машине. Которую я не просил ничего компилировать.
Дальше по дереву процессов:
launchd
└─ Cursor.app (старт 10:02)
└─ Cursor Helper (Plugin): extension-host
└─ uv tool uvx ...
Стартануло всё ровно в момент, когда я обновил Курсор.
Не понимаю какого хера вообще апдейт пошёл. Гуглю, читаю, теперь понятно.
Логично: апдейт, рестарт приложения, extension-host поднимает заново все включённые MCP-серверы.
А у меня их там зоопарк. Старые и новые, часть включённые, часть выключены.
Гипотеза номер один, неправильная.
Живым uvx в этот момент висел mcp-grafana, и палец сам потянулся к нему: вот же, Grafana MCP компилирует свои зависимости. Звучит правдоподобно.
Но привычка копать сработала. Проверяем зависимости пакета:
jq -r '.info.requires_dist' mcp-grafana.json
null
null. То есть у mcp-grafana вообще нет Python-зависимостей. Это сраный го-бинарь, завёрнутый в пип-пакет.
Ему компилировать нечего в принципе. Ну или я чего-то не знаю.
То есть я чуть не повесил вину на невиновного только потому, что он первым попался на глаза.
Обнуляю факты, копаю заново.
И вот тут честно: пока копал, гипотез было заметно больше, чем одна про grafana.
Большую часть я тут не расписываю, потому что они оказались пустышками и только сжирали время.
Просто список того, куда я успел сходить и что отмёл:
- какой-нибудь мой же зависший скрипт или забытый дев-сервер
- фоновая индексация и демоны самого курсор
- сраный докер-полупокер
- прилетевший с апдейтом фоновый апдейтер и его пост-инстал хук
- что это что-то из самого репозитория, terraform, pre-commit и компания
- майнер или малварь, ну а вдруг, паранойя должна быть здоровой
Ни одно не подтвердилось. Поэтому без разбора каждого, чтобы не растягивать.
Что компилировалось на самом деле. Смотрим, какой исходник жуёт clang, чем бы это не было:
src/core/filter/fused_filters.cc
src/core/xds/grpc/xds_http_rbac_filter.cc
...
-DGRPC_PYTHON_BUILD=1
.../sdists-v9/pypi/grpcio/1.81.0/...
-I/Users/alexk/.asdf/installs/python/3.14.3t/include/python3.14t
Это grpcio. Из исходников, uv скачал sdist, а не колесо.
Под python3.14t. Сотни C/C++ файлов gRPC, вот откуда 70-110 процессов компилятора.
А кто его притащил. mcp-grafana мы исключили. Остаётся второй uvx-сервер в конфиге, opensearch-mcp-server-py. И вот тут вторая засада: прямой зависимости на grpcio у него тоже нет. Цепочка оказалась транзитивной, в три прыжка:
opensearch-mcp-server-py
└─ opensearch-py==3.1.0
└─ opensearch-protobufs==0.19.0
└─ grpcio>=1.68.1 → 1.81.0
То есть свежий opensearch-py подтянул новый gRPC-транспорт (opensearch-protobufs), а тот тянет grpcio. И всё это в двух экземплярах сразу, потому что в конфиге у меня два opensearch-сервера:
homelab и login.linode.com. Два параллельных билда grpcio. Привет, кулеры.Почему из исходников, а не готовое колесо(wheel). Вот ключевой нюанс, ради которого вся стори. Смотрим, какие колёса есть у grpcio 1.81.0 под Python 3.14:
grpcio-1.81.0-cp314-cp314-macosx_11_0_universal2.whl
grpcio-1.81.0-cp314-cp314-manylinux2014_aarch64.whl
...
Колёса под cp314 есть. Но все они cp314-cp314.
А у меня глобальный питон через asdf вот такой:
cat ~/.tool-versions
...
python 3.14.3t
Да сука, откуда.