可塑性dpkg的奇异行为

Question

作为我工作流程的一部分，我使用的是Ubuntu服务器20.04.3。

因此，我为VM准备了映像，并使用Ansible部署它。

因为它是不能访问互联网的env，所以我安装的所有软件包都是以前下载的.deb。通过执行简单的shell命令：

dpkg -i deb_1.deb  deb_2.deb deb_3.deb deb_4.deb 
dpkg -i deb_5.deb  deb_6.deb deb_7.deb deb_8.deb 

有时~5%的情况下，我完全是偶然地收到这个错误，可以在第一次安装时发生

"stderr_lines": ["dpkg: error: dpkg frontend lock is locked by another process",
"E: Sub-process dpkg --set-selections returned an error code (2)", "E: Executing dpkg failed. Are you root?"]

我试图通过以下方式解决这一问题：

1. 列表项目

在每个安装步骤执行手动锁文件删除之前

• /var/lib/dpkg/lock
• /var/lib/dpkg/lock-前端
• /var/cache/apt/cache/lock

但是即使在手动删除之后，错误也会继续出现。

1. 尝试用Ansible apt模块和"deb“arg安装软件包--但是行为是一样的。
2. 试图找出哪个进程实际拥有带有"lsof“的锁文件，但文件不属于任何进程。

有什么办法可以解决这种奇怪的、多姿多彩的行为吗？

在系统启动时，什么进程负责创建锁文件？

Answer 1

答案是在信息中：

Executing dpkg failed. Are you root?

在更改系统拥有的位置时，需要将sudo放在命令前面。