Полное удаление пакетов в Debian и чистка их следов

Данная статья написана как гайд-шпаргалка для удаления пакетов в операционной системе Debian и будет полезна для поддержания своей системы в идеальной чистоте, избавляясь не только от самих программ, но и от всех скрытых «хвостов», кэша и конфигурационного мусора, который со временем неизменно накапливается в системе.

Проверка наличия установленных пакетов и их места нахождения на диске

Чтобы перед удалением узнать, куда именно установлены файлы пакета и где находятся его конфигурационные файлы, можно использовать утилиту dpkg. Вот основные команды:

1. Поиск установленных пакетов в системе по ключевому слову.
Выводит полный список всех установленных и зарегистрированных в системе пакетов вместе с их статусом, версией и описанием и выполняет регистронезависимый поиск подстроки firefox, отсеивая лишнее и оставляя только нужные пакеты и их зависимости:

dpkg -l | grep -i имя_пакета

Как читать статус в первой колонке:

• ii (Desired: Install, Status: Installed) — пакет полностью установлен и активен в системе.
• rc (Desired: Remove, Status: Config-files) — сам пакет удален, но его конфигурационные файлы остались в системе.
• un / pn — пакет неизвестен или был полностью вычищен.

2. Посмотреть все файлы и пути установленного пакета.
Команда выведет полный список файлов, которые пакет добавил в систему (исполняемые файлы, библиотеки, документацию):

dpkg -L имя_пакета

3. Найти конкретно конфигурационные файлы.
В выводе предыдущей команды конфигурационные файлы обычно находятся в директории /etc/. Чтобы отфильтровать список и увидеть только их, выполнить:

dpkg -L имя_пакета | grep /etc/

4. Проверить статус файлов (изменялись ли конфигурации).
Если необходимо узнать текущий статус файлов пакета (например, были ли изменены конфигурационные файлы вручную):

dpkg -s имя_пакета

Этот вывод показывает подробную информацию о состоянии и метаданных установленного пакета в системе Debian. Вот ключевые блоки:

• Status: install ok installed — пакет успешно установлен и готов к работе.
• Version: — точная версия установленного пакета (включая сборку для Raspberry Pi / Debian).
• Installed-Size: — сколько места пакет занимает на диске (в килобайтах).
• Architecture: arm64 — архитектура процессора (64-битный ARM, актуально для Raspberry Pi 3/4/5).
• Depends — список библиотек и пакетов, которые необходимы для работы (если хотя бы одной зависимости не будет, система не сможет его установить).
• Recommends / Suggests — рекомендуемые и опциональные сопутствующие пакеты (например, песочница безопасности, локализации или плагины).
• Conffiles — список конфигурационных файлов пакета в директории /etc/ с их контрольными суммами (показывает, изменялись ли они после установки).
• Conflicts - указывает на конфликтующие пакеты. Это означает, что данный пакет не может быть установлен в системе одновременно с указанными программами или библиотеками, так как они ломают его работу, используют те же конфликтующие порты/файлы или вызывают критические сбои.

Есть важный технический нюанс, о котором стоит знать: dpkg отслеживает только файлы, которые управляются самим пакетом. Этот список не включает пользовательские данные и кэш, которые программа создаёт уже в процессе работы. Например, после запуска браузера в системе появятся пользовательские профили и кэш в домашней директории: ~/.config/ и ~/.cache/.

Удаление пакета установленного в системе

Чтобы полностью удалить пакет из Debian вместе со всеми его конфигурационными файлами и больше не нужными зависимостями (которые были установлены вместе с ним и больше ничем не используются!), необходимо выполнить две команды:

1. Полное удаление пакета (включая конфиги).
Команда purge вместо обычного remove:

sudo apt purge имя_пакета

2. Удаление оставшихся «сиротских» зависимостей.
Чтобы система автоматически нашла и стерла все библиотеки и пакеты, которые больше не нужны ни одной программе:

sudo apt autoremove --purge

Совет: обе эти операции можно объединить в одну команду:

sudo apt purge --autoremove имя_пакета

Удаление явных следов от пакета оставшихся в системе

Для того чтобы зачистить систему по максимуму и не оставить вообще никаких следов после удаления пакета, нужно знать и проверить три вещи, которые пакетный менеджер (apt/dpkg) не затрагивает:

1. Пользовательские данные и кэш в домашнем каталоге.
Пакетный менеджер удаляет только системные файлы. Личные настройки программ, базы данных, кэш и профили пользователей всегда сохраняются в их домашних директориях.
Ищем скрытые папки и файлы в домашней директории ~/.config/, ~/.cache/, ~/.local/, названные в честь программы:

sudo ls -la ~/.config/
sudo ls -la ~/.cache/
sudo ls -la ~/.local/

2. Забытые конфигурационные файлы (резервные копии).
Иногда при ручном редактировании конфигов администраторы или сами программы создают файлы с расширениями .bak, .old, а также файлы с именами вроде filename.dpkg-old или filename.dpkg-dist. Команда apt purge удаляет только те файлы, которые были зарегистрированы в базе dpkg как официальные Conffiles. Всякие самодельные бэкапы в папках вроде /etc/ или /var/www/ могут остаться.

3. Автозапуск, службы и таймеры (Systemd).
Если удаляемая программа добавляла свои системные службы (.service), таймеры (.timer) или правила для udev/cron, которые находились вне стандартного пути пакета или были созданы уже после установки, они могут висеть в системе мертвым грузом. Стоит проверить: /etc/systemd/system/ и /lib/systemd/system/:

sudo ls -la /etc/systemd/system/
sudo ls -la /lib/systemd/system/

Как правильно удалить осиротевшую службу:
Остановить и отключить службу (если она еще активна):

sudo systemctl stop имя_службы
sudo systemctl disable имя_службы

Удалить файл службы вручную:

sudo rm /etc/systemd/system/имя_службы.service

(В /lib/systemd/system/ файлы обычно удаляются автоматически вместе с пакетом через apt purge, но если там что-то осталось — тоже можно удалить).

Обновить конфигурацию systemd:

sudo systemctl daemon-reload
sudo systemctl reset-failed

Удаление не явных следов от пакета (нюансы)

Даже после выполнения команды apt purge и очистки домашних директорий, в системе могут оставаться скрытые артефакты работы программ, которые пакетный менеджер не отслеживает принципиально. Это сделано для того, чтобы не удалять важные локальные плагины, специфичные сетевые настройки или глобальные кэши, если удаление было временным. Если же цель — тотальная зачистка, далее проверяю следующие системные пути:

1. Глобальные кэши пакетного менеджера (apt).
Когда устанавливается или удаляется программа, файлы самих установочных пакетов (.deb) оседают в локальном кэше системы. Со временем там накапливается много лишнего мусора. Чтобы очистить этот кэш и освободить место на диске, периодически полезно выполнять:

Очистка кэша скачанных пакетов:

sudo apt clean

Удаление кэша только для тех пакетов, которых уже нет в актуальных репозиториях:

sudo apt autoclean

2. Временные файлы и сокеты в /tmp и /run.
Некоторые приложения во время работы создают временные файлы, сокеты или PID-файлы в системных каталогах /tmp/, /var/tmp/ или /run/
Обычно эти директории автоматически очищаются при перезагрузке системы (особенно /tmp и /run, которые часто смонтированы в оперативной памяти как tmpfs).
Однако если служба завершилась некорректно или зависла перед удалением пакета, её временный файл может остаться там до следующей перезагрузки. Перезагрузка после масштабной чистки системы (sudo reboot) — всегда хороший способ убедиться, что в оперативной памяти и временных каталогах не осталось призраков удаленного софта.

3. Пользовательские данные в ~/.local/.
У современных приложений (особенно написанных на Qt/GTK или использующих Electron) есть еще одна важная директория — ~/.local/.
Внутри ~/.local/share/ программы часто создают свои базы данных, локальные хранилища, истории или плагины.
Внутри ~/.local/state/ могут храниться логи или файлы состояния конкретного пользователя.
Если программа активно использовалась, полезно проверить эти пути в домашнем каталоге.

4. Записи в планировщике задач (Cron).
Некоторые утилиты при установке добавляют собственные задания для автоматического запуска (например, проверку обновлений или очистку баз данных).
Полезно проверить системный планировщик в /etc/crontab и папки /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.weekly/.
Пользовательские задания через crontab -l. Если там осталась задача удаленной программы, cron будет постоянно выдавать ошибки в системный лог.

5. Остаточные файлы в /var/lib/ и /var/log/.
Даже после команды apt purge некоторые программы (особенно базы данных, веб-серверы или почтовые службы) специально оставляют свои рабочие директории в /var/lib/ (например, базы данных) или старые логи в /var/log/ на случай, если удаление было случайным.
Если уверены, что данные больше не понадобятся, папки программы в /var/lib/ и /var/log/ можно удалить вручную.

6. Правила брандмауэра и сетевые интерфейсы.
Если удаляемый софт создавал виртуальные сетевые интерфейсы (например, VPN-клиенты или контейнеризация вроде Docker) или прописывал собственные правила в файрвол (iptables / nftables / ufw), эти правила или интерфейсы могут остаться активными и мешать сети, пока их не убрать вручную.

7. Глобальные и пользовательские переменные окружения (PATH, export).
Некоторые программы прописывают свои пути к бинарникам или кастомные переменные в файлы конфигурации оболочки:
Системные: /etc/environment, а также файлы внутри /etc/profile.d/.
Пользовательские: ~/.bashrc, ~/.profile, ~/.zshrc (если используется zsh).
Если там остались упоминания путей удаленной программы, терминал будет выдавать ошибки вида command not found при попытке их вызова.

8. Пользовательские .desktop файлы в ~/.local/share/applications/.
Системные ярлыки программ удаляются пакетом из /usr/share/applications/, но если программа создавала свой ярлык или пользователь сохранял веб-приложение/ярлык для текущего пользователя, он останется в скрытой папке: ~/.local/share/applications/.
Если этот файл не удалить, иконка удаленной программы может продолжать мозолить глаза в меню приложений рабочего стола.

9. Пользовательские расширения, плагины и скрипты.
Многие приложения во время работы скачивают плагины, темы или расширения не в системные директории, а в личные папки пользователя (например, браузеры, редакторы кода вроде VS Code, среды разработки). Эти директории пакетный менеджер не трогает принципиально, чтобы не затереть пользовательские настройки.

10. Права и владельцы (chown / chmod).
Если приложение создавало в системе выделенного системного пользователя и группу (например, mysql, nginx, git), при apt purge они иногда остаются в системе (в файлах /etc/passwd и /etc/group), хотя сам пакет удален. Их можно удалить вручную через команды, если они больше никому не нужны:

sudo userdel имя_пользователя
sudo groupdel имя_группы

11. MIME-ассоциации и кэш рабочего стола
При установке приложения часто регистрируют себя в системе как обработчики определенных типов файлов (например, для открытия HTML-страниц, изображений или архивов). Соответствия фиксируются в пользовательском файле конфигурации ~/.config/mimeapps.list и общесистемном кэше /usr/share/applications/mimeinfo.cache.

Если файл ~/.config/mimeapps.list отсутствует, система использует глобальные значения по умолчанию. Посмотреть или отредактировать пользовательские ассоциации можно командой:

cat ~/.config/mimeapps.list
nano ~/.config/mimeapps.list

Если пакет или .desktop-ярлык уже удалены, система может по инерции хранить старые привязки или битые ссылки на иконки. Чтобы очистить хвосты и принудительно обновить базу ассоциаций и иконок в графическом окружении, необходимо выполнить:

# Обновление системной базы ярлыков и MIME-типов
sudo update-desktop-database /usr/share/applications/

# Обновление кэша иконок темы (при необходимости)
sudo gtk-update-icon-cache /usr/share/icons/hicolor/ -f

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

12. Записи в системных логах и ротация (logrotate).
Удаленная программа может оставить свои конфигурационные файлы для ротации логов в директории /etc/logrotate.d/. Хотя apt purge обычно стирает их, но если файл создавался сторонним скриптом или правил руками администратор, он может остаться и вызывать предупреждения от службы logrotate.

13. Модули ядра (DKMS и модули в /lib/modules/).
Если удаляемая программа требовала компиляции собственных модулей ядра (например, драйверы оборудования, специализированные виртуальные сети или системы защиты вроде некоторых файрволов/антивирусов), эти модули могут остаться в директории модулей ядра или в базе системы сборки DKMS. Проверить список модулей DKMS можно командой:

sudo dkms status

Если там что-то осталось от удаленного софта, это удаляется через:

sudo dkms remove ...

14. Политики безопасности (SELinux / AppArmor).
Если в системе используются строгие мандатные политики безопасности (в Debian чаще всего это AppArmor), программы часто добавляют свои профили ограничений в папку /etc/apparmor.d/. При удалении пакета через apt purge они обычно стираются, но если профиль создавался вручную или правил разработчик скрипта, файл с правилами безопасности может остаться висеть в системе и вызывать предупреждения в логах ядра (dmesg).

Правильно удалять необходимо через остановку профиля AppArmor, затем удаление самого профиля:

sudo apparmor_parser -R /etc/apparmor.d/имя_пакета
sudo rm -f /etc/apparmor.d/имя_пакета

Проверить локальные папки-исключения (на которые ссылаются строки include if exists <local/...>):

sudo rm -f /etc/apparmor.d/local/имя_пакета

Перезагрузить службу AppArmor, чтобы система окончательно забыла про эти правила:

sudo systemctl reload apparmor

Заключение

На этом список всех возможных «хвостов» в системе исчерпан — пройдя по этим шагам (от зависимостей и конфигов до домашних папок, служб и переменных окружения), можно гарантировать абсолютно чинное удаление любого ПО и поддержание домашнего сервера или рабочей станции в идеальной чистоте.