Команда apt autoremove в Debian и Ubuntu выглядит безобидно: удалить пакеты, которые больше не нужны. На практике именно она регулярно вызывает вопросы даже у опытных администраторов. Причина простая: APT работает не по интуиции, а по графу зависимостей и внутренним меткам установки. Если понимать эту логику, autoremove становится полезным инструментом обслуживания системы. Если не понимать — появляется страх удалить что-то важное, а вместе с ним привычка вообще никогда не чистить систему.
Разберём, как APT определяет лишние пакеты, что такое apt-mark manual и apt-mark auto, откуда берутся условные «осиротевшие» зависимости, как безопасно выполнять очистку и почему перед удалением почти всегда стоит запускать симуляцию.
Сразу важный тезис: apt autoremove сам по себе не опасен. Опасно использовать его без понимания, какие пакеты APT считает автоматически установленными и почему они больше не нужны. В большинстве случаев проблема не в самой команде, а в неверно размеченных пакетах или в изменившейся роли сервера.
Ещё одна причина путаницы — терминология. В обиходе часто говорят про «осиротевшие пакеты», но в APT это не отдельный официальный тип объекта. Обычно так называют пакеты, которые были поставлены как зависимости и больше не требуются ни одному вручную установленному пакету. Именно их и пытается найти и удалить autoremove.
Если у вас сервер с длинной историей изменений — ставили панели, базы данных, dev-пакеты, временные инструменты сборки, потом удаляли, — список кандидатов на автоудаление может быть длинным. Это нормально. Ненормально — запускать очистку вслепую.
Что именно делает apt autoremove
APT хранит для пакетов не только информацию о версиях и зависимостях, но и признак способа установки. Пакет может быть отмечен как установленный вручную или автоматически. Когда вы явно ставите что-то командой apt install nginx, этот пакет обычно получает статус manual. Его зависимости — библиотеки, вспомогательные компоненты, модули — часто помечаются как auto.
Дальше APT отслеживает зависимости. Пока автоматически установленный пакет нужен хотя бы одному вручную установленному пакету или другой актуальной зависимости, он остаётся в системе. Когда исходный пакет удалён, часть его зависимостей может стать никому не нужной. Вот тогда apt autoremove предлагает их убрать.
Ключевой момент: APT не определяет нужность по тому, пользуетесь ли вы программой в реальной жизни. Он не знает, что бинарник запускается из cron, что библиотека используется локальным скриптом вне пакетной модели, или что пакет вы хотите оставить на всякий случай. Он видит только дерево зависимостей и флаги auto/manual.
Именно поэтому один и тот же список к удалению может быть корректным с точки зрения пакетного менеджера, но неожиданным с точки зрения администратора. Например, вы однажды поставили метапакет, который тянул целый набор зависимостей, а потом удалили сам метапакет. Для APT это сигнал, что цепочка завершилась. Для вас же часть этих пакетов могла быть полезной отдельно.
apt autoremoveне ищет старые или редко используемые пакеты. Он удаляет только те, что помечены как автоматические и больше не удерживаются зависимостями.
Почему важны apt-mark manual и apt-mark auto
Команды apt-mark manual и apt-mark auto — главный инструмент управления поведением autoremove. Они меняют не сам пакет и не его версию, а метаданные APT: считать ли пакет установленным вручную или как зависимость.
Если у вас есть пакет, который был поставлен в составе чужой зависимости, но вы хотите сохранить его независимо от исходного родителя, пометьте его вручную. Тогда apt autoremove больше не будет рассматривать его как кандидата на удаление.
Обратная ситуация тоже встречается. Администратор вручную ставил временный пакет для диагностики, потом забыл про него, и тот остаётся в системе годами. Если вы хотите вернуть APT право убрать его при следующем пересмотре дерева зависимостей, можно перевести пакет в auto. Но делать это стоит осознанно.
Практически это выглядит так: если вы понимаете, что пакет является частью постоянной роли сервера, разумно проверить, не надо ли зафиксировать его как manual. Особенно это касается утилит, которые запускаются внешними скриптами, системами CI, локальными сервисами или вручную администратором, но не связаны явной зависимостью с другими пакетами.
apt-mark showmanual
apt-mark showauto
apt-mark manual curl
apt-mark auto curlКоманды apt-mark showmanual и apt-mark showauto полезны не только для проверки отдельных случаев, но и для общей ревизии системы. На минимальном сервере список manual-пакетов обычно хорошо читается и отражает реальную роль узла. Если там хаос, это сигнал, что пакетная история сервера давно требует инвентаризации.
Когда apt autoremove действительно полезен
Самый очевидный сценарий — удаление больших пакетов или целых ролей. Например, вы ставили среду сборки, компиляторы, заголовки, отладочные библиотеки, потом пакет проекта больше не нужен. После apt remove остаётся шлейф зависимостей, который и убирает apt autoremove.
Второй частый случай — обновление между версиями дистрибутива. После апгрейда Debian или Ubuntu система может удерживать набор пакетов, актуальных для прошлой конфигурации. APT корректно предложит часть из них к очистке, если они больше ни на что не влияют.
Третий сценарий — контейнеры и шаблоны образов. Там важно сокращать размер и исключать лишние компоненты. Но именно в контейнерах многие выполняют очистку автоматически, не проверяя результат. Для продакшена такой подход хорош только при воспроизводимой сборке, где роли пакетов строго известны.
На обычном сервере регулярная умеренная очистка тоже полезна: уменьшается поверхность сопровождения, меньше ненужных библиотек остаётся после старых задач, проще понимать текущее состояние узла. Но это должно быть именно обслуживание, а не механический ритуал.
Если вы запускаете прикладные сервисы на VDS, такой подход особенно полезен: чем понятнее набор пакетов на узле, тем легче обновления, диагностика и пересборка окружения.
Как безопасно запускать autoremove: сначала симуляция
Главное правило безопасной очистки — сначала смотрим, потом удаляем. У APT для этого есть режим симуляции. Он показывает, что именно будет сделано, не внося изменений в систему. Для серверов это обязательный шаг, особенно если узел работает давно или на нём вручную правили пакетное состояние.
apt -s autoremoveКлюч -s означает simulation. В выводе вы увидите список пакетов, которые будут удалены. Этот список нужно не просто бегло просмотреть, а проверить на предмет пакетов, которые фактически используются, но могут считаться вторичными с точки зрения APT.
Если среди кандидатов есть ожидаемые библиотеки, старые модули и временные инструменты — скорее всего, всё в порядке. Если же там оказались важные утилиты, ядра, пакеты сети, базы данных, агенты мониторинга или что-то, что напрямую отражает назначение сервера, остановитесь и разберитесь, почему они попали в список.
Полезный рабочий шаблон такой:
- Обновить индексы пакетов.
- Посмотреть список кандидатов через симуляцию.
- Для подозрительных пакетов проверить их метку и обратные зависимости.
- При необходимости перевести нужные пакеты в manual.
- Только потом запускать реальное удаление.
apt update
apt -s autoremove
apt-mark showauto
apt-mark showmanualЕсли параллельно занимаетесь общей ревизией сервера, удобно сразу проверять и другие узкие места производительности. Например, для PHP-узлов может пригодиться материал про разбор slowlog в PHP-FPM.
Как понять, почему пакет хотят удалить
Самый правильный вопрос при просмотре кандидатов не «можно ли удалить этот пакет?», а «почему APT считает, что он больше не нужен?». Ответ обычно находится в одном из трёх мест: пакет помечен как auto, его родительский пакет удалён, или он удерживался метапакетом, который больше не установлен.
Для начала проверьте статус пакета через apt-mark. Если он auto, уже понятно, почему autoremove на него смотрит. Затем имеет смысл изучить зависимости и обратные зависимости. Даже если пакет ни от чего больше не зависит, важно понять, не используется ли он вашей логикой вне пакетной модели.
Например, пакет rsync может вызываться из резервного скрипта, но не быть обязательной зависимостью ни одного установленного приложения. Если он по какой-то причине оказался в состоянии auto, APT не увидит смысла его сохранять. Для пакетного менеджера это просто исполнимый файл без входящих зависимостей.
То же касается CLI-инструментов, агентов мониторинга, библиотек для локально собранного ПО и пакетов, оставленных после миграций. Поэтому список на удаление нужно сопоставлять не только с APT, но и с реальной эксплуатацией сервера.
apt-mark showauto | grep '^rsync$'
apt-cache rdepends --installed rsync
apt-cache depends rsyncТипичные причины неожиданного списка
Чаще всего неожиданности возникают не из-за ошибки APT, а из-за истории изменений на сервере. Ниже — ситуации, которые регулярно приводят к спорным кандидатам на удаление.
Удалили метапакет, но хотите оставить его содержимое
Метапакеты часто ничего не делают сами, а только тянут набор зависимостей. Это особенно заметно у пакетов окружений, desktop-компонентов, серверных стеков и некоторых облачных пресетов. После удаления метапакета его содержимое может быстро стать лишним для APT.
Если вы хотите сохранить отдельные элементы набора, заранее отметьте их как manual. Иначе они попадут в цепочку на автоудаление.
Временная установка для миграции или отладки
Поставили утилиту, собрали пакет, проверили гипотезу, забыли. Через месяц уже непонятно, нужна ли она. В такой ситуации apt autoremove полезен, но только после сверки с рабочими скриптами и cron-задачами.
Переиспользование старого сервера под новую роль
Сервер был под PHP, потом стал под Node.js, затем превратился в reverse proxy. Пакетная база хранит следы всех эпох. APT может предлагать очистить много старого, и в целом это правильно. Но иногда среди старых пакетов остаются нужные мелочи: агенты, CLI, отладочные утилиты, cron-инструменты.
Ручные манипуляции с пакетами
Использование dpkg -i, нестандартных репозиториев, pinning, ручного удаления без понимания зависимостей — всё это делает картину менее очевидной. Сам APT при этом остаётся логичен, но администратору становится сложнее восстановить причину текущего состояния.
Практический безопасный сценарий очистки
Если нужен надёжный и повторяемый подход для Debian и Ubuntu, используйте простой регламент. Он особенно уместен на продакшен-серверах, где любая неожиданность дороже, чем лишние пять минут проверки.
- Сохраните актуальный список вручную установленных пакетов.
- Запустите симуляцию
apt autoremove. - Проверьте кандидатов, которые относятся к сервисам, сети, резервному копированию, мониторингу и админским утилитам.
- Если нужный пакет оказался кандидатом, отметьте его как manual.
- Повторите симуляцию и убедитесь, что список стал ожидаемым.
- Только затем выполните реальную очистку.
apt-mark showmanual > /root/manual-packages-before-cleanup.txt
apt -s autoremove
apt-mark manual rsync curl ca-certificates
apt -s autoremove
apt autoremoveСмысл такого подхода в том, что вы сначала стабилизируете намерения. Если пакет важен для роли сервера — зафиксируйте это в APT. Тогда дальнейшие очистки будут предсказуемее.
На инфраструктуре, где серверы живут долго и меняют назначение, полезно хранить список ключевых manual-пакетов в документации или в системе конфигурации. Тогда пересоздание узла и его ревизия становятся гораздо проще.
Если проект размещён на виртуальном хостинге, таких задач обычно меньше, потому что пакетной базой управляет провайдер. А вот на VPS и выделенных окружениях контроль за пакетами уже целиком на администраторе.
Нужно ли использовать purge вместе с autoremove
Отдельный вопрос — стоит ли выполнять удаление с очисткой конфигураций. По умолчанию apt autoremove убирает пакеты, но не обязательно удаляет все их конфиги. Иногда это удобно: можно быстро вернуть пакет. Иногда наоборот хочется убрать весь след старой роли.
Здесь нет универсального ответа. На сервере, где вы цените быстрый rollback, лучше сначала ограничиться обычным удалением. Если же вы сознательно вычищаете старую подсистему и уверены, что конфиги больше не нужны, можно использовать режим с purge, но только после симуляции и понимания последствий.
apt -s autoremove --purge
apt autoremove --purgeБудьте особенно осторожны, если у пакета в /etc лежали вручную настроенные файлы, которые могут пригодиться как образец. С точки зрения чистоты системы purge полезен, с точки зрения операционной практики — не всегда.
Что делать, если нужный пакет уже попал под автоудаление
Если вы заметили это на этапе симуляции — отлично, проблема решается в одну команду:
apt-mark manual имя-пакетаПосле этого повторите apt -s autoremove и проверьте, исчез ли пакет из списка кандидатов. Если исчез — логика восстановлена.
Если же вы уже выполнили очистку и удалили лишнее, сценарий обычно тоже не катастрофический: пакет можно установить заново. Но неприятность в том, что вместе с ним могли исчезнуть вспомогательные зависимости, а часть конфигов при purge могла быть потеряна. Поэтому гораздо дешевле потратить время на симуляцию, чем потом восстанавливать рабочее состояние по памяти.
Полезные привычки для Debian и Ubuntu
- Не запускайте автоочистку автоматически на важных серверах без просмотра списка кандидатов.
- После ручной установки критичных CLI-инструментов проверяйте, не стоит ли отметить их как manual.
- После миграции роли сервера делайте ревизию manual/auto-статусов.
- Перед крупными чистками сохраняйте список вручную установленных пакетов.
- Не путайте кэш пакетов и автоудаление зависимостей: это разные задачи.
Последний пункт особенно важен. Очистка кэша через apt clean или apt autoclean освобождает место в кеше пакетов, а apt autoremove работает с установленными пакетами и зависимостями. Эти команды часто упоминают рядом, но они решают разные проблемы.
Итоги: когда apt autoremove безопасен
apt autoremove безопасен тогда, когда вы понимаете две вещи: как APT трактует зависимости и какие пакеты помечены как manual или auto. В Debian и Ubuntu это не магия и не чёрный ящик, а вполне прозрачный механизм.
Если коротко, надёжная схема выглядит так: сначала симуляция, затем анализ подозрительных кандидатов, при необходимости apt-mark manual, и только потом реальное удаление. Такой подход превращает очистку в управляемую операцию, а не в игру на удачу.
Для администратора главное не в том, чтобы никогда ничего не удалять, а в том, чтобы состояние системы отражало её текущую роль. Именно в этом смысле аккуратная очистка полезна: меньше мусора, понятнее пакетная база, ниже риск тащить в продакшен хвосты старых задач.
И если после чтения статьи у вас останется одна рабочая привычка, пусть это будет она: перед любым apt autoremove сначала запускайте apt -s autoremove. Эта одна команда спасает чаще, чем кажется.
