Debian/Ubuntu: apt-daily, unattended-upgrades и блокировки APT — как понять и безопасно снять lock

Ошибка could not get lock в Debian и Ubuntu знакома почти каждому администратору. Обычно она появляется в самый неудобный момент: вы заходите по SSH, хотите быстро поставить пакет, обновить индексы или доустановить зависимость, а APT отвечает, что база заблокирована. Наиболее частые формулировки — блокировка /var/lib/dpkg/lock-frontend, /var/lib/dpkg/lock, /var/cache/apt/archives/lock или /var/lib/apt/lists/lock.

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

В современных Debian и Ubuntu чаще всего виноваты службы автоматического обслуживания пакетов: apt-daily, apt-daily-upgrade и unattended-upgrades. Они запускаются через таймеры systemd и периодически обновляют индексы, скачивают пакеты, а иногда и устанавливают обновления безопасности. Поэтому запросы вроде Debian apt lock, Ubuntu apt could not get lock и systemd timers apt — это фактически про одну и ту же историю.

Отдельная проблема в том, что в интернете до сих пор полно вредных советов уровня «просто удали файл lock и всё заработает». Иногда после этого действительно кажется, что стало лучше. Но если в этот момент реально работает apt или dpkg, можно получить битое состояние пакетной базы, зависшие триггеры и частично распакованные пакеты. После этого без восстановления уже не обойтись.

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

Какие блокировки APT бывают и что они означают

Хотя в разговоре обычно говорят просто «APT заблокирован», на деле есть несколько разных lock-файлов. От них зависит и причина, и правильный способ реакции.

/var/lib/dpkg/lock-frontend

Это блокировка фронтенда, которую используют apt, apt-get, unattended-upgrades и другие высокоуровневые инструменты. Чаще всего именно её вы видите при установке пакета: E: Could not get lock /var/lib/dpkg/lock-frontend.

Обычно это означает, что уже идёт другая операция установки, обновления или удаления пакетов. Например, фоновый запуск unattended-upgrades после загрузки сервера.

/var/lib/dpkg/lock

Это более низкоуровневая блокировка самой базы dpkg. Если занята она, значит прямо сейчас меняется состояние пакетов: распаковка, конфигурация, выполнение postinst/prerm-скриптов, обновление статуса в /var/lib/dpkg/status.

Если вы видите именно dpkg lock, действовать нужно особенно осторожно: грубое вмешательство здесь опаснее всего.

/var/lib/apt/lists/lock

Эта блокировка связана с обновлением списков пакетов, то есть с операцией наподобие apt update. Её часто держит apt-daily, который обновляет индексы репозиториев автоматически.

Если занят только этот lock, то пакетная база может быть в порядке, а система просто в фоне выполняет обновление метаданных.

/var/cache/apt/archives/lock

Этот файл относится к кэшу скачанных пакетов. Обычно он удерживается во время загрузки .deb-файлов. Самая безопасная реакция в таком случае — сначала понять, продолжается ли активная работа по сети и диску, а не спешить что-то удалять.

Почему блокировки появляются сами по себе: apt-daily и unattended-upgrades

В Debian и особенно в Ubuntu автоматические задания APT давно стали нормой. После загрузки машины или по расписанию systemd запускает таймеры, которые проверяют репозитории, подтягивают индексы и могут применять автоматические обновления.

Чаще всего участвуют такие сущности:

• apt-daily.timer — отвечает за периодический запуск обновления индексов и служебных задач APT;
• apt-daily-upgrade.timer — запускает установку автоматических обновлений;
• apt-daily.service — реальный сервис, который выполняет фоновую работу;
• apt-daily-upgrade.service — сервис автоматической установки обновлений;
• unattended-upgrades.service — механизм автоматической установки, чаще всего обновлений безопасности.

Из-за этого типичный сценарий выглядит так: сервер только что перезагрузился, вы быстро заходите на него и запускаете apt install, а в ту же секунду уже стартовал apt-daily. В результате вы получаете could not get lock, хотя на самом деле ничего не сломано.

Если машина только что загрузилась, первым подозреваемым почти всегда будет не «битый APT», а фоновая автозадача systemd.

Особенно часто это встречается на новых VPS, свежих контейнерах, облачных образах и тестовых машинах, где обновления ещё не успели завершиться после первого старта.

Если тема таймеров systemd у вас всплывает не только в APT, но и в планировщиках фоновых задач, полезно отдельно разобрать, как устроены cron, crontab и systemd timers и чем они отличаются в реальной эксплуатации.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

С чего начать диагностику

Первая задача — не лечить вслепую, а выяснить, кто именно держит lock. Для этого достаточно нескольких безопасных команд.

1. Посмотреть активные процессы APT и DPKG

ps -ef | egrep 'apt|dpkg|unattended' | grep -v grep

Если вы видите активный apt, apt-get, dpkg или unattended-upgrade, не спешите убивать процесс. Сначала оцените, это живой процесс или давно зависший.

2. Понять, какой процесс держит конкретный lock

sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock
sudo lsof /var/lib/apt/lists/lock
sudo lsof /var/cache/apt/archives/lock

Команда lsof показывает PID и имя процесса, открывшего файл. Это самый прямой ответ на вопрос «кто владелец блокировки».

Если lsof не установлен, можно использовать:

sudo fuser -v /var/lib/dpkg/lock-frontend
sudo fuser -v /var/lib/dpkg/lock
sudo fuser -v /var/lib/apt/lists/lock
sudo fuser -v /var/cache/apt/archives/lock

3. Проверить состояние systemd-сервисов и таймеров

systemctl status apt-daily.service apt-daily-upgrade.service unattended-upgrades.service

systemctl list-timers --all | egrep 'apt-daily|apt-daily-upgrade'

Если сервис активен, это уже хороший знак: значит, APT не обязательно сломан, а просто занят штатной задачей. Команда со списком таймеров помогает понять, что именно запускается по расписанию и когда был последний старт.

4. Посмотреть журнал

journalctl -u apt-daily.service -u apt-daily-upgrade.service -u unattended-upgrades.service --no-pager -n 100

Журнал полезен, когда непонятно, процесс реально работает или уже завершился с ошибкой. Там часто видно скачивание индексов, установку обновлений, ожидание сети или сбой maintainer scripts.

Когда нужно просто подождать

Во многих случаях лучший вариант — ничего не делать 1–5 минут. Это звучит банально, но именно так чаще всего и решается проблема apt lock. Если в логах видно, что apt-daily обновляет списки, а процесс живой, безопаснее дождаться его завершения.

Особенно стоит подождать, если:

• сервер только что загрузился;
• в системе давно не делались обновления, и фоновая задача может качать много пакетов;
• идёт установка обновлений безопасности;
• процесс dpkg использует CPU или диск, а не висит мёртвым грузом.

Чтобы наблюдать за изменениями, удобно открыть второй терминал и смотреть состояние служб:

watch -n 2 'systemctl is-active apt-daily.service apt-daily-upgrade.service unattended-upgrades.service'

Когда сервисы перейдут в состояние inactive, можно повторить вашу команду apt.

Когда допустимо остановить фоновые задания

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

Сначала пробуем мягкую остановку:

sudo systemctl stop apt-daily.service apt-daily-upgrade.service unattended-upgrades.service

После этого ещё раз смотрим, остались ли процессы и держится ли блокировка:

ps -ef | egrep 'apt|dpkg|unattended' | grep -v grep
sudo lsof /var/lib/dpkg/lock-frontend

Если сервис уже заканчивал критичный этап, он может остановиться не мгновенно. Это нормально.

Важно понимать разницу: остановить сервис systemd — это разумный шаг, а сразу делать kill -9 по dpkg — почти всегда плохая идея. Жёсткое убийство оправдано только если вы точно установили, что процесс завис безвозвратно и другого выхода нет.

Что делать, если процесс завис или APT был прерван

Настоящая проблема начинается не тогда, когда lock существует, а когда пакетный менеджер остался в незавершённом состоянии. Например, оборвалась SSH-сессия во время обновления, машина внезапно перезагрузилась, закончилось место на диске или кто-то уже успел вручную удалить lock-файлы.

Признаки такого состояния:

• активных процессов apt, dpkg уже нет;
• но при попытке установки продолжают появляться ошибки про блокировку или прерванный dpkg;
• APT сообщает, что нужно вручную выполнить dpkg --configure -a;
• в журнале есть сообщения о недоконфигурированных пакетах.

Безопасная последовательность восстановления обычно такая.

Шаг 1. Убедиться, что живых процессов нет

ps -ef | egrep 'apt|dpkg|unattended' | grep -v grep

Если процессов нет, можно переходить дальше. Если есть — сначала разберитесь с ними.

Шаг 2. Восстановить конфигурацию пакетов

sudo dpkg --configure -a

Это ключевая команда после прерванной установки. Она запускает конфигурирование пакетов, которые уже распакованы, но не были доведены до конца.

Шаг 3. Исправить зависимости

sudo apt -f install

Если в системе остались недостающие зависимости или конфликтующее состояние, эта команда часто завершает ремонт.

Шаг 4. Обновить индексы и проверить целостность

sudo apt update
sudo apt upgrade

После восстановления полезно убедиться, что APT снова работает штатно.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Нужно ли вручную удалять lock-файлы

Короткий ответ: почти никогда. Сам lock-файл не является причиной проблемы, он лишь маркер блокировки. Если процесс ещё работает, удаление файла не остановит его корректно и не снимет реальную конкуренцию за базу. Если процесса уже нет, lock-файл чаще всего и так не мешает после восстановления состояния.

Ручное удаление стоит рассматривать только в очень узком сценарии:

• вы точно проверили, что процессов apt, apt-get, dpkg и unattended-upgrades нет;
• система не выполняет фоновые задания systemd;
• команды восстановления всё равно упираются именно в оставшийся stale lock;
• вы понимаете, почему это произошло, например после аварийного завершения контейнера.

Даже в таком случае сначала логичнее выполнить dpkg --configure -a, а не начинать с удаления lock-файлов.

Если первым движением при ошибке APT стало удаление lock, вы почти наверняка пропустили этап нормальной диагностики.

Как временно отключить apt-daily и unattended-upgrades

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

Для временного отключения таймеров:

sudo systemctl stop apt-daily.timer apt-daily-upgrade.timer
sudo systemctl disable apt-daily.timer apt-daily-upgrade.timer

Если требуется и остановка уже стартовавших сервисов:

sudo systemctl stop apt-daily.service apt-daily-upgrade.service unattended-upgrades.service

Проверка:

systemctl list-timers --all | egrep 'apt-daily|apt-daily-upgrade'

Для систем, где установлен пакет unattended-upgrades, можно дополнительно проверить его настройки в файлах конфигурации APT. Но прежде чем отключать автоматические обновления на продакшене, ответьте себе на вопрос: кто и как будет закрывать security-обновления вместо них.

Если вы администрируете публичные сервисы, не откладывайте и базовую защиту трафика: для веб-проектов и панелей управления пригодятся SSL-сертификаты, а для изоляции сервисов и демонов — материал про усиление безопасности systemd на VDS.

Практический сценарий для SSH: быстрый и безопасный runbook

Если нужно короткое рабочее правило для дежурства, используйте такой порядок.

1. Не удаляйте lock-файлы сразу.
2. Посмотрите активные процессы apt, dpkg, unattended-upgrades.
3. Проверьте владельца lock через lsof или fuser.
4. Посмотрите статус apt-daily и apt-daily-upgrade через systemd.
5. Если идёт штатная работа — подождите завершения.
6. Если нужно срочно — мягко остановите сервисы systemd.
7. Если пакетная база прервана — выполните dpkg --configure -a, затем apt -f install.
8. Только после полной проверки рассматривайте ручное удаление stale lock.

Как отличить «долго работает» от «зависло»

Это самый практичный вопрос, потому что внешне оба случая выглядят одинаково: вы не можете выполнить apt install. Ориентируйтесь на косвенные признаки.

Скорее всего, процесс живой, если:

• в journalctl появляются новые строки;
• PID существует и не меняется часами в состоянии зомби;
• есть I/O-активность или сетевые соединения к зеркалам репозиториев;
• на машине медленный диск, слабый CPU или медленный канал, и обновление объективно может идти долго.

Подозрение на зависание сильнее, если:

• процесс висит очень долго без изменений в логах;
• в логе повторяются одни и те же ошибки;
• закончилось место на разделе /var или корне;
• сломано DNS-разрешение, недоступны зеркала или есть проблемы с сетью;
• maintainer script ожидает интерактивного ввода в неподходящей среде.

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

Почему это особенно важно в автоматизации

В Ansible, cloud-init, CI-джобах и bootstrap-скриптах блокировки APT часто проявляются как «случайные» падения. На практике они редко случайны: просто сценарий стартует раньше, чем завершатся системные таймеры apt-daily. Поэтому в автоматизации полезно либо явно ждать окончания фоновых сервисов, либо заранее контролировать их запуск.

Типичная ошибка — добавлять в скрипт бесконечные циклы удаления lock-файлов. Это маскирует симптом, но не решает проблему гонки. Гораздо правильнее дождаться завершения systemd-задачи или аккуратно остановить её перед управляемым изменением пакетов.

Итоги

Ошибки could not get lock, apt lock и dpkg lock в Debian и Ubuntu чаще всего связаны не с поломкой, а с параллельной работой штатных механизмов: apt-daily, apt-daily-upgrade, unattended-upgrades и соответствующих таймеров systemd. Поэтому первый шаг — понять, кто держит блокировку, а не удалять файлы наугад.

Безопасная стратегия проста: определить владельца lock, посмотреть статус сервисов и журнал, подождать штатное завершение или мягко остановить фоновые задания, если ситуация требует срочного вмешательства. Если же пакетная операция была реально прервана, восстановление почти всегда начинается с dpkg --configure -a и проверки зависимостей.

Именно такой подход сохраняет пакетную базу в рабочем состоянии и избавляет от гораздо более неприятных последствий, чем сама блокировка APT.