Как исправить ошибку «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». Если да – обязательно поделитесь в комментах, какой метод помог именно вам.
Если ни один из перечисленных способов так и не помог вам справиться с проблемой, опять же – дайте знать. Я постараюсь вам помочь.
Любые другие предложения также приветствуются в комментариях.
