Dpkg ошибка dpkg frontend lock заблокирована другим процессом

Recently I was trying to install an application using the apt command on Ubuntu when I encountered the following error:

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?

In fact, there is a similar error you may see:

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?

In some cases, you might see it while using the Software Center:

These errors are very similar to another common Ubuntu error, Unable to lock directory /var/cache/apt/archives/, and the interesting thing is that the fixes are similar as well.

Fixing “Unable to lock the administration directory (/var/lib/dpkg/)” error

You see this error because some other program is trying to update Ubuntu. When a command or application is updating the system or installing a new software, it locks the dpkg file (Debian package manager).

This locking is done so that two processes don’t change the content at the same time as it may lead to unwarranted situation and a possible broken system.

Let’s see what steps can you take to fix this issue of ‘unable to lock administration directory’.

Method 0:

The first thing you should do is to check if some other program could be running system update or installing a program.

If you are using command line, check if an application like Software Center, Software Updater, Synaptic package manager, Gdebi is running any update/installation. If that’s the case, please wait for the program to finish the running process.

If there is no such application running, please check all the open terminal windows and see if you are running an update or installing a program. If yes, wait for it to finish.

If none of the above is happening, check which other process is running the apt command (package manager for handling software). Use this command:

ps aux | grep -i apt

For me, it showed this output:

[email protected]:~$ 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

If you see that apt is being used by a program like apt.systemd.daily update, you are in luck, my dear reader.

This is a daemon that runs in the background and check for system updates automatically when you start your system.

In Ubuntu 18.04 and higher versions, it may even try to download and install the important security updates on its own. At least this is what I see in the default settings in Software & Updates tool on the Ubuntu desktop.

If you are on Ubuntu server, you may check whether you have unattended upgrades enabled by checking the content of the file /etc/apt/apt.conf.d/20auto-upgrades.

So if you see apt.systemd.daily is using the apt process, all you have to do is to wait for a few minutes. When the automatic update finishes, you should be able to install your software as usual.

As a permanent solution, you may disable the check for automatic update and unattended upgrades altogether however I won’t advise that for security reasons.

Now, that was the simple scenario and it could be handled easily. But that might not always be the case. If some other program is using apt, you need to handle it differently.

Method 1:

Use the Linux command line to find and kill the running process. To do that, use the command below:

ps aux | grep -i apt

This will show you the id of the process running apt or apt-get. In the example below, the process id is 7343. You can ignore the last line containing ‘grep –color=auto’.

You can use the process id to terminate it by sending the SIGTERM signal. Replace the <process_id> with the number you got in the output of previous command.

sudo kill <process_id>

Check if the process was killed by running the ‘ps aux | grep -i apt’ command. If it is still running, force kill it with SIGKILL signal:

sudo kill -9 <process_id>

Another easier way would be to use the killall command. This will kill all the instances of a running program:

sudo killall apt apt-get

Method 2

The above method would fix the problem for you in most cases. But my case was a bit different. I was updating my system and accidentally closed the terminal. For that reason, there were no processes running apt, but it still showed me the error.

In this case, the root cause is the lock file. As mentioned earlier, the lock files are used to prevent two or more processes from using the same data. When apt or apt-get commands are run, they create lock files in a few places. If the previous apt command was not terminated properly, the lock files are not deleted and hence they prevent any new instances of apt-get or apt commands.

To fix the problem, all you need to do is to remove the lock files. But before you do that, it would be a good idea to stop any process that is using the lock files.

Use the lsof command to get the process ID of the process holding the lock files. Check the error and see what lock files it is complaining about and get the id of the processes holding these lock files.

Run these commands one by one.

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

It’s possible that the commands don’t return anything, or return just one number. If they do return at least one number, use the number(s) and kill the processes like this (replace the <process_id> with the numbers you got from the above commands):

sudo kill -9 <process_id>

You can now safely remove the lock files using the commands below:

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

After that, reconfigure the packages:

sudo dpkg --configure -a

Now if you run the sudo apt update command, everything should be fine.

Troubleshooting 1: “Unable to acquire the dpkg frontend lock”

If you see an error like this:

[email protected]:~$ 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?

You should find out which process is holding the lock-frontend using the lsof command as discussed in previous sections:

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

This is what it showed for me:

[email protected]:~$ 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

If you see ‘unattende‘ COMMAND column, this means unattended security upgrades are running. You should wait for the process to finish. Basically, this is what I discussed in method 0 but you probably skipped that.

If the COMMAND is something else, you may kill the process and then remove the lock file. You can see the process id under the PID column. Use this PID to kill the process. After that, remove the lock file and run the update command to see if it’s been fixed.

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

What’s that lsof: warning can’t stat() fuse.gvfsd-fuse file system?

Note: If you see “lsof: warning can’t stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete” lines after running the earlier mentioned lsof command, don’t panic.

That’s not an error. It’s just that lsof tries to look into mounted file systems as well and the warning is about those mounted systems.

The files are locked by the processes on your main filesystem so if it shows some warning and no output, this only means that there is no process using those lock files.

Troubleshooting 2: “dpkg: error: dpkg frontend is locked by another process”

If you see the error “dpkg frontend is locked by another process” while running the steps in method 2, you need to one additional step.

First, find out the id of the process that is holding the lock file.

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

The above command will give you the details of the processes using the lock files. Use the process ID to kill this program:

sudo kill -9 PID

Now you can remove the lock and reconfigure dpkg:

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

Did it work for you? Which method fixed it for you?

I hope this small tip helped you fix the “Could not get lock /var/lib/dpkg/lock” error. If yes, please let me know which method worked for you in the comments.

If you are still facing issues, let me know. I’ll try to help you out.

Any other suggestions are also welcome in the comments.

Recently I was trying to install an application using the apt command on Ubuntu when I encountered the following error:

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?

In fact, there is a similar error you may see:

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?

In some cases, you might see it while using the Software Center:

These errors are very similar to another common Ubuntu error, Unable to lock directory /var/cache/apt/archives/, and the interesting thing is that the fixes are similar as well.

Fixing “Unable to lock the administration directory (/var/lib/dpkg/)” error

You see this error because some other program is trying to update Ubuntu. When a command or application is updating the system or installing a new software, it locks the dpkg file (Debian package manager).

This locking is done so that two processes don’t change the content at the same time as it may lead to unwarranted situation and a possible broken system.

Let’s see what steps can you take to fix this issue of ‘unable to lock administration directory’.

Method 0:

The first thing you should do is to check if some other program could be running system update or installing a program.

If you are using command line, check if an application like Software Center, Software Updater, Synaptic package manager, Gdebi is running any update/installation. If that’s the case, please wait for the program to finish the running process.

If there is no such application running, please check all the open terminal windows and see if you are running an update or installing a program. If yes, wait for it to finish.

If none of the above is happening, check which other process is running the apt command (package manager for handling software). Use this command:

ps aux | grep -i apt

For me, it showed this output:

[email protected]:~$ 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

If you see that apt is being used by a program like apt.systemd.daily update, you are in luck, my dear reader.

This is a daemon that runs in the background and check for system updates automatically when you start your system.

In Ubuntu 18.04 and higher versions, it may even try to download and install the important security updates on its own. At least this is what I see in the default settings in Software & Updates tool on the Ubuntu desktop.

If you are on Ubuntu server, you may check whether you have unattended upgrades enabled by checking the content of the file /etc/apt/apt.conf.d/20auto-upgrades.

So if you see apt.systemd.daily is using the apt process, all you have to do is to wait for a few minutes. When the automatic update finishes, you should be able to install your software as usual.

As a permanent solution, you may disable the check for automatic update and unattended upgrades altogether however I won’t advise that for security reasons.

Now, that was the simple scenario and it could be handled easily. But that might not always be the case. If some other program is using apt, you need to handle it differently.

Method 1:

Use the Linux command line to find and kill the running process. To do that, use the command below:

ps aux | grep -i apt

This will show you the id of the process running apt or apt-get. In the example below, the process id is 7343. You can ignore the last line containing ‘grep –color=auto’.

You can use the process id to terminate it by sending the SIGTERM signal. Replace the <process_id> with the number you got in the output of previous command.

sudo kill <process_id>

Check if the process was killed by running the ‘ps aux | grep -i apt’ command. If it is still running, force kill it with SIGKILL signal:

sudo kill -9 <process_id>

Another easier way would be to use the killall command. This will kill all the instances of a running program:

sudo killall apt apt-get

Method 2

The above method would fix the problem for you in most cases. But my case was a bit different. I was updating my system and accidentally closed the terminal. For that reason, there were no processes running apt, but it still showed me the error.

In this case, the root cause is the lock file. As mentioned earlier, the lock files are used to prevent two or more processes from using the same data. When apt or apt-get commands are run, they create lock files in a few places. If the previous apt command was not terminated properly, the lock files are not deleted and hence they prevent any new instances of apt-get or apt commands.

To fix the problem, all you need to do is to remove the lock files. But before you do that, it would be a good idea to stop any process that is using the lock files.

Use the lsof command to get the process ID of the process holding the lock files. Check the error and see what lock files it is complaining about and get the id of the processes holding these lock files.

Run these commands one by one.

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

It’s possible that the commands don’t return anything, or return just one number. If they do return at least one number, use the number(s) and kill the processes like this (replace the <process_id> with the numbers you got from the above commands):

sudo kill -9 <process_id>

You can now safely remove the lock files using the commands below:

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

After that, reconfigure the packages:

sudo dpkg --configure -a

Now if you run the sudo apt update command, everything should be fine.

Troubleshooting 1: “Unable to acquire the dpkg frontend lock”

If you see an error like this:

[email protected]:~$ 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?

You should find out which process is holding the lock-frontend using the lsof command as discussed in previous sections:

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

This is what it showed for me:

[email protected]:~$ 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

If you see ‘unattende‘ COMMAND column, this means unattended security upgrades are running. You should wait for the process to finish. Basically, this is what I discussed in method 0 but you probably skipped that.

If the COMMAND is something else, you may kill the process and then remove the lock file. You can see the process id under the PID column. Use this PID to kill the process. After that, remove the lock file and run the update command to see if it’s been fixed.

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

What’s that lsof: warning can’t stat() fuse.gvfsd-fuse file system?

Note: If you see “lsof: warning can’t stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete” lines after running the earlier mentioned lsof command, don’t panic.

That’s not an error. It’s just that lsof tries to look into mounted file systems as well and the warning is about those mounted systems.

The files are locked by the processes on your main filesystem so if it shows some warning and no output, this only means that there is no process using those lock files.

Troubleshooting 2: “dpkg: error: dpkg frontend is locked by another process”

If you see the error “dpkg frontend is locked by another process” while running the steps in method 2, you need to one additional step.

First, find out the id of the process that is holding the lock file.

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

The above command will give you the details of the processes using the lock files. Use the process ID to kill this program:

sudo kill -9 PID

Now you can remove the lock and reconfigure dpkg:

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

Did it work for you? Which method fixed it for you?

I hope this small tip helped you fix the “Could not get lock /var/lib/dpkg/lock” error. If yes, please let me know which method worked for you in the comments.

If you are still facing issues, let me know. I’ll try to help you out.

Any other suggestions are also welcome in the comments.

Описание проблемы. Ошибка

При выполнении в Ubuntu команды вида:

sudo apt install someprogram

в терминале появляется ошибка:

E: Не удалось получить доступ к файлу блокировки /var/lib/dpkg/lock-frontend - open (11: Ресурс временно недоступен)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

Ошибка может появляться не только при выполнении apt install, но и при любых других действиях с apt или apt-get.

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

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?

Как исправить

Данные ошибки появляются, когда программа apt-get (apt) не может получить доступ к файлу блокировки /var/lib/dpkg/lock*. Данный файл используется, чтобы запретить одновременное выполнение операций, связанных с управлением пакетами в системе, так как при одновременном изменении данных о пакетах будет нарушена целостность «пакетной базы».

Обычно существует две основные причины появления, описанных выше ошибок:

1. В данный момент уже выполняется экземпляр программы apt-get (apt).
2. Предыдущий вызов apt-get (apt) завершился некорректно.

Способ первый

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

ps aux | grep -i apt

Вывод команды может быть следующим:

root 9425 0.0 0.0 79516 3752 pts/1 S+ 10:31 0:00 sudo apt-get install inkscape
pingvin+ 9456 0.0 0.0 38892 944 pts/0 S+ 10:32 0:00 grep --color=auto -i apt

В первой строке мы видим, что уже есть работающий экземпляр программы apt-get, который имеет PID (идентификатор) 9425. Вторая строка относится к нашей команде grep, которую мы запустили с аргументом apt, поэтому она вывела саму себя. Итак, нас интересует только первая строка.

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

sudo kill -9 9425

После выполнения данной команды, процесс с идентификатором 9425 завершится.

Можно воспользоваться еще одним простым способом — это завершить все экземпляры программ apt и apt-get сразу. Для этого можно выполнить команду:

sudo killall apt apt-get

Способ второй

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

Нам нужно удалить все файлы блокировки. Для этого выполняем команды:

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

Если при выполнении каких-нибудь из этих команд появится сообщение: rm: невозможно удалить ’/var/../lock’: Нет такого файла или каталога, это нормально, не обращайте на него внимания.

После этого нужно выполнить переконфигурацию (донастройку) пакетов:

sudo dpkg --configure -a

Заключение

Мы рассмотрели два способа решения ошибок, связанных с доступом к файлу блокировки dpkg. Как правило, эти способы помогают. Если у вас остались какие-либо вопросы, оставляйте их в комментариях.