Паспорт генерации изображения
Промт генерации изображения
Dark neon 'underside of progress' scene, cyberpunk workshop mood. A cold teal-cyan extinguished daemon-process crumbling to ash, killed; but from the ash its warm amber phoenix-copy rises again at once, resurrected not by the system but by a parent application window opening nearby; cold snuffed service versus amber rebirth. Drifting embers and sparks, charred circuitry, fine ash particles, fan hum, smoky haze. Deep shadow, volumetric haze, warm amber and cyan color palette, shallow depth of field, cinematic film still on 35mm, intricately detailed, ultra-detailed, fine textures, rich layered background, ornate mechanical detail, sharp focus, moody atmosphere.
История о демоне-фениксе, который научил меня, что «отключено» в системе не всегда означает «мертво».
На домашнем сервере крутится мой собственный монитор ресурсов - простой скрипт, который раз в пять минут пишет в лог load average, память, своп и топ процессов. Заводил его, чтобы ловить деградацию стека умного дома. Поймал совсем другое.
Среди ночи мониторинг ресурсов выплюнул аномалию. В логе resmon.log, который каждые пять минут фиксирует состояние машины, промелькнула строка, похожая на системный сбой. Load average подскочил до 36.98 при обычном диапазоне в 2-4 единицы. Своп за один пятиминутный интервал прибавил 1.1 ГБ.
Машина не зависла, но задышала тяжело, как после резкого удара по процессору и памяти.
Привычные подозреваемые
Первые мысли ушли в сторону тех, кто обычно ест ресурсы на этом сервере. Весь вечер крутился ffmpeg - транскодирование видео забирает 20-40% мощности в фоновом режиме. Параллельно работал python с YOLO-детектором: на пиках движения в кадре он легко выжирает до 200% CPU.
Казалось, профиль нагрузки понятен. К тому же была уверенность в «чистоте» системы от старых хвостов: Keystone, предыдущий апдейтер Google, был вырезан и отключен ещё в прошлой сессии. Считал эту задачу закрытой, поставив на ней ментальную галочку.
Однако скачок в логах не был похож на плавный рост нагрузки от нейронки или предсказуемый ритм ffmpeg. Это был резкий, агрессивный всплеск, который возник из ниоткуда и так же быстро затих.
Имя в сыром логе
Вместо того чтобы гадать, пришлось спуститься на уровень сырых данных. Прямое чтение лога за ту самую минуту показало виновника по имени:
2026-07-15 22:57:22 | load:36.98/24.56/12.36 | mem:4040M used | swap:1656M | top: Google(88.6%) GoogleUpdater(51.6%) Google(16.9%) [SWAP+1115M]GoogleUpdater. Тот самый процесс, который должен был остаться в прошлом.
Появилось закономерное недоумение: если plist-файл в launchd отключен, откуда взялся процесс? Система не должна была его запускать. Но машина не врет - GoogleUpdater не просто запустился, он устроил настоящий погром в оперативной памяти и забил очередь процессора.
Эксперимент вместо догадки
Я обратился к ИИ, чтобы проверить гипотезу о том, как демон мог вернуться. Вместо того чтобы предлагать список команд для удаления файлов, напарник предложил провести чистый причинный тест: проверить связь между родительским приложением и его «тенью».
Гипотеза была простой: что, если апдейтер - это не независимый системный демон, а временная надстройка самого браузера?
Проверка заняла минуту. Команда на закрытие Chrome:
osascript -e 'quit app "Google Chrome"'Результат был мгновенным. GoogleUpdater исчез из списка процессов вместе с браузером. Ни одного активного потока, ни одного нового plist-файла в системных папках.
Выяснилось, что Chrome пересоздаёт своего апдейтера при каждом старте. Он не ждёт команды от системы, он сам разворачивает инфраструктуру обновления внутри своей сессии. Отключение Keystone в launchd убило демона один раз, но не лишило Chrome права воскрешать его снова и снова.
Выбор между баном и гигиеной
Технически проблему можно было решить грубо: заблокировать исполняемый файл апдейтера на уровне прав доступа или создать жесткое правило в системе, запрещающее запуск конкретного бинарника.
Но был нюанс: браузер всё ещё нужен для работы. Полностью «забанить» механизм обновления в современных приложениях часто означает начать войну с их внутренними проверками целостности, которая заканчивается либо нестабильностью, либо бесконечными окнами с ошибками.
Решение оказалось проще и честнее: Chrome просто не должен висеть в памяти в фоновом режиме, когда он не используется. Вместо того чтобы пытаться «вылечить» приложение, которое считает своё право на самообновление абсолютным, я выбрал гигиену запуска.
Изнанка контроля
Эта история подсветила одну важную вещь: мы привыкли думать об автозапуске как о иерархии, где launchd или планировщик задач являются высшей инстанцией. Если мы закрыли дверь в системе, значит, процесс не войдёт.
Но современный софт всё чаще переходит на модель «внутреннего управления». Приложение становится маленькой операционной системой внутри большой. Оно само решает, когда создать вспомогательный процесс, как его назвать и когда убить.
Реальный рычаг управления в таком случае смещается. Бесполезно пытаться отключить автозапуск демона, если его пересоздаёт не система, а сам родительский апп. Единственный действенный метод контроля здесь - решать, разрешено ли самому приложению вообще находиться в памяти.
Иногда самая эффективная «починка» - это не правка конфига, а простое закрытие окна.
Часть темы «Вторая жизнь железа» - там собраны остальные разборы про слабое и старое железо.