Как исправить ошибку «E: Could not get lock /var/lib/dpkg/lock» в Ubuntu Linux

Недавно, устанавливая приложение с помощью команды apt в Ubuntu, я столкнулся со следующей ошибкой:

E: Could not get lock /var/lib/dpkg/lock – open (11: Resource
temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another
process using it?

Если вы столкнётесь с какой-то из перечисленных ниже ошибок, знайте, фактически у вас та же ошибка, что и у меня:

E: Could not get lock /var/lib/apt/lists/lock – open (11: Resource
temporarily unavailable)
E: Unable to lock directory /var/lib/apt/lists/
E: Could not get lock /var/lib/dpkg/lock – open (11: Resource temporarily
unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another
process using it?

В некоторых случаях подобные ошибки возникают при использовании Центра программного обеспечения.

И в целом, они напоминают еще одну распространенную ошибку:

Unable to lock directory/var/cache/apt/archives/ и, как говорится "подобное лечится подобно", а похожие ошибки и фиксятся похоже.

Как исправить ошибку «Unable to lock the administration directory (/var/lib/dpkg/)»

Вы видите эту ошибку, потому что какая-то другая программа обновляет Ubuntu прямо сейчас. Когда команда или приложение обновляют систему или устанавливают новое программное обеспечение, они блокируют файл dpkg (менеджер пакетов Debian).

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

Давайте посмотрим, что мы можем сделать, чтобы решить проблему «unable to lock the administrator directory».

Метод 0:

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

Если вы используете командную строку, проверьте, не запускает ли одно из следующих приложений: Software Center, Software Updater, менеджер пакетов Synaptic или Gdebi, какое-нибудь обновление / установку. В случае положительного ответа – просто подождите, пока программа завершит выполнение.

Если ни одно из этих приложений не запущено, проверьте все открытые окна терминала и посмотрите, не запустили ли вы самостоятельно какие-либо обновление или установки. Если да, дождитесь завершения этих процессов. (Совет странный, но помните, что все мы бываем невнимательны))

Если ничего из вышеперечисленного не происходит, проверьте, какой еще процесс выполняет команду apt (менеджер пакетов для работы с программным обеспечением). Используйте эту команду:

ps aux | grep -i apt

В моем случае команда вернула такой результат:

abhishek@nuc:~$ ps aux | grep -i apt
root 1464 0.0 0.0 4624 772 ? Ss 19:08 0:00 
/bin/sh /usr/lib/apt/apt.systemd.daily update 
root 1484 0.0 0.0 4624 1676 ? S 19:08 0:00 
/bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held update 
_apt 2836 0.8 0.1 96912 9432 ? S 19:09 0:03 
/usr/lib/apt/methods/http 
abhishek 6172 0.0 0.0 21532 1152 pts/1 S+ 19:16 0:00 
grep --color=auto -i apt

Если вы, как и я, видите, что apt используется такой программой, как apt.systemd.daily update, вам повезло, мой дорогой читатель.

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

В Ubuntu 18.04 и более поздних версиях он может даже попытаться загрузить и установить важные обновления безопасности самостоятельно. По крайней мере, такие опции я увидел в дефолтных настройках в инструменте «Программное обеспечение и обновления» на рабочем столе Ubuntu.

Если вы находитесь на сервере Ubuntu, вы можете проверить, включены ли у вас автоматические обновления, проверив содержимое файла /etc/apt/apt.conf.d/20auto-upgrades.

Итак, если вы выяснили, что apt.systemd.daily использует процесс apt, все, что вам нужно сделать, это подождать несколько минут. Когда автоматическое обновление завершится, вы сможете установить свое программное обеспечение как обычно.

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

Это был самый простой и легко побеждаемый сценарий. К сожалению, он не единственный возможный. Если apt использует какая-то другая программа, то и решение будет другим.

Метод 1:

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

ps aux | grep -i apt

Эта команда покажет вам идентификатор процесса, выполняющего apt или apt-get. В приведенном ниже примере идентификатор процесса - 7343. Не обращайте внимания на последнюю строку, содержащую «grep –color = auto».

Вы можете использовать идентификатор процесса, чтобы завершить его, отправив команду SIGTERM. Замените <process_id> числом, которое вы получили в выводе предыдущей команды.

sudo kill < process_id > 

Проверьте, был ли процесс остановлен, запустив команду «ps aux | grep -i apt» еще раз. Если он все еще работает, принудительно уничтожьте его сигналом SIGKILL:

sudo kill -9 < process_id > 

Другой, более простой способ - использовать команду killall, она убьет все экземпляры запущенной программы:

sudo killall apt apt-get

Метод 2:

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

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

Чтобы решить эту проблему, все, что вам нужно сделать, это удалить файлы блокировки. Но, прежде чем вы это сделаете, было бы неплохо остановить любой процесс, использующий файлы блокировки.

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

Последовательно запустите эти команды:

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

Возможно, команды ничего не будут возвращают или вернут только одно число. Но, если они возвращают хотя бы одно число, используйте его, чтобы завершить такие процессы (замените <process_id> числами, полученными из приведенных выше команд):

sudo kill -9 < process_id > 

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

sudo rm /var/lib/apt/lists/lock 
sudo rm /var/cache/apt/archives/lock 
sudo rm /var/lib/dpkg/lock

После этого переконфигурируйте пакеты:

sudo dpkg --configure -a

Теперь, если вы запустите команду sudo apt update, все должно работать как надо.

Устранение неполадки: «Unable to acquire the dpkg frontend lock»

Если вы видите такую ​​ошибку:

abhishek@nuc:~$ sudo apt install grub-customizer 
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource
temporarily unavailable) 
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend),
is another process using it?

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

sudo lsof /var/lib/dpkg/lock-frontend

В моем случае команда вернула:

abhishek@nuc:~$ sudo lsof /var/lib/dpkg/lock-frontend 
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system 
/run/user/1000/gvfs 
          Output information may be incomplete. 
COMMAND   PID  USER FD  TYPE DEVICE  SIZE/OFF NODE NAME 
unattende 2823 root 5uW REG  8,2 0   145221 
/var/lib/dpkg/lock-frontend

Если вы видите значение «unattende» в столбце COMMAND, это значит, что выполняются автоматические обновления безопасности. Вам следует дождаться завершения процессов. По сути, это то, что я описывал в методе 0, но вы могли его пропустить.

Если значение COMMAND какое-то другое, вы можете убить процесс, а затем удалить файл блокировки.  Идентификатор процесса вы найдете в столбце PID. Используйте этот PID, чтобы убить процесс. После этого удалите файл блокировки и запустите команду обновления, чтобы проверить, исправили ли вы проблему.

sudo kill -9 PID 
sudo rm /var/lib/dpkg/lock-frontend 
sudo apt update 

Устранение неполадки: «dpkg: error: dpkg frontend is locked by another process»

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

Во-первых, узнайте идентификатор процесса, хранящего файл блокировки.

sudo lsof /var/lib/dpkg/lock-frontend

Эта команда предоставит вам подробную информацию о процессах и программах, использующих файлы блокировки. Используйте идентификатор процесса, чтобы убить эту программу:

sudo kill -9 PID

Теперь вы можете снять блокировку и перенастроить dpkg:

sudo rm /var/lib/dpkg/lock-frontend 
sudo dpkg --configure -a

Помогла ли вам статья? Какой из методов помог в вашем случае?

Надеюсь, этот небольшой пост помог вам исправить ошибки типа «Не удалось получить lock / var / lib / dpkg / lock». Если да – обязательно поделитесь в комментах, какой метод помог именно вам.

Если ни один из перечисленных способов так и не помог вам справиться с проблемой, опять же – дайте знать. Я постараюсь вам помочь.

Любые другие предложения также приветствуются в комментариях.