# Apt отвечает «Could not get lock /var/lib/dpkg/lock»: кто держит блокировку, сколько ждать и почему нельзя удалять lock-файлы

**URL:** <https://kryptos.forum/t/apt-otvechaet-could-not-get-lock-var-lib-dpkg-lock-kto-derzhit-blokirovku-skolko-zhdat-i-pochemu-nelzya-udalyat-lock-fajly/196>\
**Category:** Виртуальные машины и серверы\
**Tags:** виртуальные-машины\
**Created:** [30.Сентябрь.2026 09:37:38 UTC](https://kryptos.forum/t/apt-otvechaet-could-not-get-lock-var-lib-dpkg-lock-kto-derzhit-blokirovku-skolko-zhdat-i-pochemu-nelzya-udalyat-lock-fajly/196 "2026-09-30T09:37:38Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![team\_vm](https://kryptos.forum/letter_avatar_proxy/v4/letter/t/779978/32.png) [@team\_vm](https://kryptos.forum/u/team_vm)\
**Post date:** [30.Сентябрь.2026 09:37:38 UTC](https://kryptos.forum/t/apt-otvechaet-could-not-get-lock-var-lib-dpkg-lock-kto-derzhit-blokirovku-skolko-zhdat-i-pochemu-nelzya-udalyat-lock-fajly/196/1 "2026-09-30T09:37:38Z")

</div>

**Что было.** На сервере с Ubuntu команда `apt install` отвечает: `E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr)`. Никто другой пакеты не ставил.

**Причина.** В фоне работала служба автоматических обновлений безопасности (`unattended-upgrades`), которая запускается по таймеру и в момент установки держит блокировку менеджера пакетов. Модератор посоветовал просто подождать; автор подтвердил. Позже та же ситуация повторилась при обновлении выпуска, что тоже нормально: инструмент обновления держит блокировку часами.

**Что делать правильно.**

1. Прочитать сообщение: современные версии apt сами пишут, какой процесс держит блокировку. Если это `unattended-upgr`, `apt-daily-upgrade`, `packagekitd` или `do-release-upgrade`, дождаться окончания: `journalctl -u apt-daily-upgrade -f` покажет прогресс, `ps -fp <PID>` подтвердит, что процесс жив.
2. Если процесс не назван: `sudo fuser -v /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock /var/cache/apt/archives/lock` или `lsof` по тем же путям.
3. Если держатель мёртв (PID не существует), а файл остался (после жёсткой перезагрузки во время установки): удалить только конкретный lock-файл и сразу `sudo dpkg --configure -a`, чтобы завершить прерванные настройки. Удалять lock-файлы при живом процессе нельзя: два параллельных dpkg над одной базой пакетов ломают её.

**Почему «убить процесс и удалить lock» плохой совет из интернета.** Убитый посреди работы `dpkg` оставляет пакеты в состоянии «распакован, не настроен»; следующая команда apt откажется работать до `dpkg --configure -a`, а в худшем случае придётся разбирать сломанные скрипты пакетов вручную.

**Как уменьшить столкновения на сервере.**

- Знать расписание: `systemctl list-timers apt-daily*` покажет, когда идут проверки и установки; окно можно сдвинуть переопределением `OnCalendar` у `apt-daily-upgrade.timer`.
- Для машин, которыми управляют централизованно (скрипты, средства конфигурации), отключить автоматическую установку (`APT::Periodic::Unattended-Upgrade "0"` в `/etc/apt/apt.conf.d/20auto-upgrades`) и обновлять из своего конвейера.
- Не запускать вторую сессию с apt «в другом окне»; для долгих операций использовать `tmux`.

**Отличать от других блокировок.** `lock-frontend` держит интерактивный apt, `lock` держит dpkg, `lists/lock` держит `apt update`; сообщение называет файл, и держатель у каждого свой.

Команда описана в [документации Ubuntu](https://manpages.ubuntu.com/manpages/noble/en/man8/apt.8.html).