Я вижу, что почти все ответы рекомендуют удалить блокировку. Это никогда не должно быть сделано, всегда предпочтительнее убить dpkg (который должен быть устойчивым к такого рода событиям), чем даже думать об удалении его файла блокировки (где его присутствие не указывает на удерживаемую блокировку). Блокировки устанавливаются, когда запущен процесс dpkg или apt процесс, и снимаются (при необходимости ядром), когда процессы завершаются или уничтожаются. Более новые dpkg и apt версии будут печатать PID процесса, содержащего оспариваемый файл блокировки, и aptтеперь даже ждут по умолчанию освобождения блокировок. Это описано в FAQ по dpkg .
Если вы попытаетесь:
sudo fuser -vik -TERM /var/lib/dpkg/lock /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock
sudo dpkg --configure --pending
это предложит завершить любой процесс, который в настоящее время содержит эти файлы блокировки, которые после уничтожения снимут блокировки. Если вы видите apt-get процесс или aptitude процесс, который выглядит зависшим, его уничтожение должно быть менее опасным, чем когда система упаковки находится в процессе установки пакета. Если процессы действительно зависли и у вас нет другого выбора, вам может потребоваться убить их, передав -KILL вместо -TERM. Затем вам нужно завершить все ожидающие настройки, чтобы dpkg привести их в лучшее состояние, а также чтобы он мог также интегрировать обновления своего журнала в основную базу данных состояния.
Непосредственное уничтожение dpkg процесса, если он присутствует, как правило, не лучшая идея, потому что, если dpkg активен, какой-то сценарий сопровождающего может выполнять действия, которые не устойчивы к внезапному завершению (или сбоям), но внутри dpkg должен быть устойчивым к таким внезапным завершениям. , и это предпочтительнее, чем удалять любой файл блокировки, который имеет гораздо более высокий шанс повредить как базу данных dpkg, так и файловую систему.
Уничтожение внешнего интерфейса, такого как процесс apt-getor aptitude, хотя и не идеально, но в целом намного безопаснее.
