在Ubuntu Linux中如何修复Could not get lock /var/lib/dpkg/lock错误
在Ubuntu上安装应用程序看到类似的错误：
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?
Could Not Get Lock Error in Ubuntu Software Center
这些错误与另一个常见的Ubuntu错误非常相似，即无法锁定目录/ var / cache / apt / archives /，有趣的是，修复程序也相似。
修复“Unable to lock the administration directory (/var/lib/dpkg/)” 错误
我们会看到此错误，因为其他某个程序正在尝试更新Ubuntu。当命令或者应用程序更新系统或者安装新软件时，它将锁定dpkg文件(Debian软件包管理器)。
进行此锁定是为了使两个进程不会同时更改内容，因为这可能会导致不必要的情况以及可能的系统损坏。
方法：
我们应该做的第一件事是检查是否有其他程序正在运行系统更新或者安装程序。
如果使用命令行，请检查软件中心，软件更新程序，Synaptic软件包管理器，Gdebi之类的应用程序是否正在运行任何更新/安装。如果是这种情况，请等待程序完成运行过程。
如果没有正在运行的此类应用程序，请检查所有打开的终端窗口，并查看我们是否正在运行更新或者安装程序。如果是，请等待完成。
如果以上均未发生，请检查哪个其他进程正在运行apt命令(用于处理软件的程序包管理器)。使用此命令：
ps aux | grep -i apt
对我来说，它显示了以下输出：
theitroad@localhost:~$ 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.systemd.daily update之类的程序正在使用apt，那么我们好运，亲爱的读者。
这是一个后台运行的守护程序，在启动系统时会自动检查系统更新。
在Ubuntu 18.04和更高版本中，它甚至可能尝试自行下载并安装重要的安全更新。至少我在Ubuntu桌面上的"软件和更新"工具的默认设置中看到了这一点。
Ubuntu可能会在后台安装安全更新
如果我们使用的是Ubuntu服务器，则可以通过检查文件/etc/apt/apt.conf.d/20auto-upgrades的内容来检查是否启用了无人参与的升级。
因此，如果我们看到apt.systemd.daily正在使用apt进程，那么我们要做的就是等待几分钟。自动更新完成后，我们应该能够照常安装软件。
如果其他程序正在使用apt，则需要以不同的方式处理它。
方法1：
使用Linux命令行查找并终止正在运行的进程。为此，请使用以下命令：
ps aux | grep -i apt
这将显示运行apt或者apt-get的进程的ID。在下面的示例中，进程ID为7343. 我们可以忽略包含grep color = auto'的最后一行。
我们可以通过发送SIGTERM信号来使用进程ID终止它。将<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命令获取持有锁定文件的进程的进程ID。检查错误并查看其抱怨的锁定文件，并获取包含这些锁定文件的进程的ID。
逐一运行这些命令。
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命令，一切应该都很好。
故障排除1：无法获取dpkg前端锁
如果看到这样的错误：
theitroad@localhost:~$ 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
这是对我显示的：
theitroad@localhost:~$ 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
如果看到无人参与的COMMAND列，则表明无人参与的安全升级正在运行。我们应该等待该过程完成。基本上，这就是我在方法0中讨论的内容，但是我们可能跳过了。
如果命令是其他命令，则可以终止该进程，然后删除锁定文件。我们可以在" PID"列下看到进程ID。使用此PID终止进程。之后，删除锁定文件并运行update命令以查看其是否已修复。
sudo kill -9 PID sudo rm /var/lib/dpkg/lock-frontend sudo apt update
故障排除2：dpkg：错误：dpkg前端被另一个进程锁定
如果在运行方法2中的步骤时看到错误dpkg前端被另一进程锁定，则需要执行另一个步骤。
首先，找出持有锁定文件的进程的ID。
sudo lsof /var/lib/dpkg/lock-frontend
上面的命令将为我们提供使用锁定文件的详细过程。使用进程ID杀死该程序：
sudo kill -9 PID
现在，我们可以删除锁定并重新配置dpkg：
sudo rm /var/lib/dpkg/lock-frontend sudo dpkg --configure -a
