Службы телеметрии в Ubuntu съедают память и их стоит отключить вручную

Свежая Ubuntu с рабочим столом GNOME после загрузки занимает примерно 1,6-2 ГБ оперативной памяти, хотя пользователь ещё не открыл ни одного приложения. Часть этого объёма расходуют службы, о которых при установке никто не спрашивал: сборщик отчётов о сбоях, пересыльщик данных на серверы Canonical, индексатор файлов и целый пласт инфраструктуры Snap. Инженерный подход здесь прост, как таблица умножения: сначала измерить, потом убрать лишнее, потом снова измерить. Разберём весь путь по шагам, с готовыми командами и честными цифрами того, что реально освободится.

Инвентаризация памяти в свежей системе перед любыми изменениями

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

free -h
systemd-cgtop -m --batch
ps aux --sort=-%mem | head -n 12

Первая строка показывает общую картину: объём, занятый процессами, и реально доступный резерв. Вторая сортирует группы systemd по потреблению памяти, и в этом списке на свежей системе сразу всплывают кандидаты: snapd, snap-store, whoopsie, tracker-miner-fs-3. Третья команда выводит дюжину самых прожорливых процессов с точными значениями в мегабайтах. Типичные наблюдения для чистой Ubuntu 22.04 выглядят так: служба snapd удерживает порядка 100-150 МБ, магазин приложений snap-store в фоне добавляет ещё 200-300 МБ, whoopsie стабильно держит 20-40 МБ, а индексатор tracker во время прохода по домашнему каталогу может подниматься до 300-800 МБ с пиками загрузки процессора. Складываем только постоянных жильцов и получаем 300-500 МБ, которые тратятся на то, что пользователь никогда не заказывал. Запишите значения free -h в блокнот: после всех манипуляций эта цифра станет аргументом, сильнее любых рассуждений. К слову, колонка available в выводе честнее колонки used: ядро отдаёт буферы и кэш под нужды приложений, поэтому пугаться трёх занятых гигабайт из восьми не стоит, реальный запас указан именно в available. Для сравнения состояния до и после важна только она.

Whoopsie и apport, служебная связка для сбора отчётов о сбоях

В Ubuntu две службы работают в связке, когда приложение падает. apport перехватывает сбой, собирает дампы и складывает их в каталог /var/crash, а whoopsie берёт эти отчёты и отправляет на серверы Canonical. Обе запускаются автоматически на любом десктопе. Польза от них есть, но скромная: обычный пользователь отчёты всё равно не читает, а место в /var/crash постепенно распухает.

Через графический интерфейс отправку можно лишь приостановить: открывается Параметры, затем раздел Конфиденциальность, пункт Диагностика, и там выключаются два переключателя, отвечающих за отправку отчётов об ошибках в Canonical и о работе программ. Это останавливает отправку, но сами службы продолжают жить в памяти. Полное решение выглядит иначе:

sudo systemctl disable --now whoopsie.service
sudo apt purge -y whoopsie whoopsie-preferences
sudo systemctl disable --now apport.service
sudo sed -i 's/enabled=1/enabled=0/' /etc/default/apport
sudo apt purge -y apport apport-gtk
sudo rm -rf /var/crash/*

Первая команда останавливает пересыльщика и убирает его из автозагрузки, вторая сносит пакеты целиком. Третья и четвёртая выключают сам механизм сбора: правка файла /etc/default/apport нужна потому, что некоторые обработчики сбоев смотрят именно в него. Потери минимальны: если в будущем понадобится сообщить разработчикам о падении, отчёт можно собрать и отправить вручную, когда это действительно уместно.

Snap и snapd, тяжёлая упаковка с постоянными фоновыми расходами

Формат Snap хорош для разработчиков: один архив работает во всех редакциях Ubuntu, обновляется сам и живёт в изолированном контуре. Расплата ложится на пользователя. Каждый установленный пакет монтируется как отдельный squashfs-раздел через loop-устройство, служба snapd всегда сидит в памяти, а магазин snap-store запускается в фоне даже тогда, когда его никто не открывал. Проверить это просто:

snap list
lsblk | grep -c loop

Команда snap list покажет набор предустановленных пакетов, среди которых обычно firefox, gnome-42-2204, snap-store и gtk-common-themes, а подсчёт loop-устройств удивит даже владельца только что установленной системы: счёт идёт на десятки. Если решение о полном отказе от Snap принято, порядок действий должен быть строгим, иначе можно остаться без браузера:

1. сначала добавляется репозиторий Mozilla и устанавливается обычная deb-сборка firefox, чтобы интернет ни на минуту не пропал;
2. затем все снап-пакеты удаляются одним циклом, каждая операция размонтирует свой squashfs-раздел;
3. после этого сносится сам каркас snapd и ставится блокировка пакета, чтобы обновления не вернули его обратно;
4. в конце вычищаются оставшиеся каталоги, освобождая от 600 МБ до 1 ГБ диска.

Отдельного внимания заслуживает приоритет репозитория Mozilla: без явного закрепления менеджер пакетов при ближайшем обновлении может подменить deb-сборку обратно на транзишнл-пакет, который снова потянет snap. Закрепление делается одним файлом:

sudo tee /etc/apt/preferences.d/mozilla-firefox <<'EOF'
Package: *
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 1001
EOF

Вся последовательность в готовом виде:

sudo add-apt-repository -y ppa:mozillateam/ppa
sudo apt update
sudo apt install -y firefox
for s in $(snap list | awk 'NR>1 {print $1}'); do sudo snap remove --purge "$s"; done
sudo apt purge -y snapd
sudo apt-mark hold snapd
sudo rm -rf /snap /var/snap /var/lib/snapd ~/snap

Цикл с awk берёт имена пакетов из snap list и передаёт их на удаление по очереди, поэтому ручной перебор не понадобится. Строка apt-mark hold страхует от сюрпризов: без неё очередное обновление может снова притащить snapd в систему. Итог по памяти на типичной установке составляет 250-450 МБ, а вместе с исчезновением десятка loop-устройств заметно бодрее начинает себя чувствовать и дисковая подсистема.

Tracker, встроенный индексатор файлов с неуместным аппетитом

Индексатор tracker в Ubuntu 22.04 существует уже в третьей версии и обслуживает полнотекстовый поиск GNOME: содержимое документов, фотографии, музыку. Работает он от имени пользователя, поэтому управляется не через sudo, а через пользовательский контур systemd. Проблема в поведении: после первой установки или подключения внешнего диска служба tracker-miner-fs-3.service методично обходит все файлы, нагружая процессор и память часами, а прожорливость её корпорации-помощников tracker-extract-3.service и tracker-miner-rss-3.service доходит до сотен мегабайт. На слабых машинах это выражается в гудении кулера без видимой причины.

Индексы лежат в каталогах ~/.cache/tracker3 и ~/.local/share/tracker3 и со временем отъедают гигабайты. Безопасный способ заглушить индексацию без риска сломать зависимости пакетов выглядит так:

systemctl --user stop tracker-miner-fs-3.service tracker-extract-3.service tracker-miner-rss-3.service
systemctl --user mask tracker-miner-fs-3.service tracker-extract-3.service tracker-miner-rss-3.service
rm -rf ~/.cache/tracker3 ~/.local/share/tracker3

Команда mask жёстче, чем disable: замаскированные юниты нельзя запустить даже случайно, через зависимости. Поиск в файловом менеджере при этом не пропадает, потому что Nautilus умеет искать по имени, напрямую сканируя каталоги. Теряется лишь полнотекстовый поиск внутри содержимого документов в отдельных приложениях, и для большинства рабочих сценариев эта потеря незаметна. Тем, кто хочет вычистить пакеты до конца, подойдёт вариант sudo apt purge -y tracker tracker-extract tracker-miner-fs-3, но перед подтверждением стоит внимательно прочитать, какие пакеты apt собрался удалить заодно: менеджер иногда захватывает соседние компоненты GNOME.

ubuntu-report и другие точки отправки данных в сеть

Отдельный сюжет появился в Ubuntu начиная с версии 17.10: утилита ubuntu-report однократно собирает сведения об оборудовании, языке, часовом поясе и выборе, сделанном при установке системы, и отправляет их разработчикам. Данные обезличены, объём невелик, но сам факт незаметной отправки отчёта многим не нравится, тем более что после установки утилита остаётся в системе навсегда. Отказ оформляется одной командой, которая записывает решение в локальный профиль:

ubuntu-report send no
sudo apt purge -y ubuntu-report

Графическая альтернатива существует: в окне приветствия Добро пожаловать в Ubuntu при первом входе достаточно выбрать вариант отказа от отправки сведений. Тот, кто уже успел пропустить это окно, может выполнить команду выше, результат будет тем же.

Пока речь зашла о мусоре, стоит пройтись и по журналам. Системный журнал systemd растёт без ограничений по умолчанию и на старых установках достигает нескольких гигабайт:

sudo journalctl --vacuum-size=200M
sudo sed -i 's/#SystemMaxUse=/SystemMaxUse=200M/' /etc/systemd/journald.conf
sudo systemctl restart systemd-journald.service

Первая команда подрезает архив до 200 МБ прямо сейчас, правка конфигурации закрепляет этот потолок на будущее. Служба журналирования после перезапуска продолжит работу в новом режиме, и диск больше не будет тихо заполняться отчётами за прошлые годы.

Проверка результата и подсчёт реально освобождённой памяти

Работа завершена перезагрузкой, после которой все замеры повторяются с нуля. Сравнение с записанными в начале значениями free -h показывает характерную картину: машина с 4 ГБ памяти после входа в систему занимает вместо 1,9-2 ГБ около 1,2-1,3 ГБ, то есть в распоряжении пользователя оказывается на 500-700 МБ больше. На 8 ГБ эффект менее драматичен в процентах, но заметен в скорости отклика при переключении между тяжёлыми приложениями и в отсутствии пиков подкачки.

Контрольный список занимает три команды:

free -h
systemd-cgtop -m --batch
lsblk | grep -c loop

В списке групп больше не должно быть whoopsie и snapd, а счётчик loop-устройств падает с нескольких десятков до нуля или единицы. Логичным завершением станет уборка осиротевших зависимостей: sudo apt autoremove --purge -y удалит библиотеки, оставшиеся после снесённых пакетов, и ещё чуть-чуть разгрузит диск. Через неделю стоит повторить замер: если память снова подтягивается к прежним значениям, виновником обычно оказывается возвращённый обновлением snapd, и строка apt-mark hold в этом случае напомнит о себе очень кстати.

Возврат функциональности, если отключённое всё же понадобится

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

sudo apt install -y whoopsie apport apport-gtk ubuntu-report
sudo systemctl enable --now whoopsie.service
sudo sed -i 's/enabled=0/enabled=1/' /etc/default/apport

Для индексатора достаточно снять маску с пользовательских юнитов: systemctl --user unmask tracker-miner-fs-3.service, после чего служба сама досканирует накопившиеся файлы. Возврат Snap начинается с разблокировки пакета командой sudo apt-mark unhold snapd и завершается установкой каркаса заново.

Главный вывод из всей операции лежит немного в стороне от команд. Десктопная система не обязана терпеть в памяти жильцов, которые не приносят владельцу пользы: каждая фоновая служба должна оправдать своё резидентное существование хотя бы пониманием того, что она делает. Пара вечеров с systemctl и apt превращают Ubuntu из любезно наблюдающего за пользователями продукта в обычный рабочий инструмент, поведение которого полностью понятно. А предсказуемость, как известно любому инженеру, стоит дороже лишних ста мегабайт.