| Message ID | 20231208101253.4042712-3-changqing.li@windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | rpm: workaround to remove dnf lock file | expand |
On Fri, 8 Dec 2023 at 11:13, Changqing Li <changqing.li@eng.windriver.com> wrote: > dnf has a bug, refer [1], it cause that log_lock.pid may not removed > after dnf exit. And for native dnf, since we change the lock file path > to /, it will never be removed, and make the rootfs not clean,refer > [2][3]. This patch is a workaround to fix above issue. > @@ -420,3 +422,7 @@ class RpmPM(PackageManager): > os.chdir(current_dir) > > return tmp_dir > + > + def _remove_dnf_lock_file(self): > + if os.path.exists(self.rootfs_dir + "/log_lock.pid") > + os.remove(self.rootfs_dir + "/log_lock.pid") Both the description and the code in the patch seem to imply that sometimes dnf leaves the lock file behind and sometimes it does not. If that is the case, we need to dig deeper into the reasons why. If that is not the case, please change the removal to be deterministic (remove the existence check), so that it produces an error if the lock file is not actually left behind by dnf. That way we'll also know when upstream resolved the issue, if ever. Alex
On 12/8/23 18:21, Alexander Kanavin wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Fri, 8 Dec 2023 at 11:13, Changqing Li > <changqing.li@eng.windriver.com> wrote: >> dnf has a bug, refer [1], it cause that log_lock.pid may not removed >> after dnf exit. And for native dnf, since we change the lock file path >> to /, it will never be removed, and make the rootfs not clean,refer >> [2][3]. This patch is a workaround to fix above issue. >> @@ -420,3 +422,7 @@ class RpmPM(PackageManager): >> os.chdir(current_dir) >> >> return tmp_dir >> + >> + def _remove_dnf_lock_file(self): >> + if os.path.exists(self.rootfs_dir + "/log_lock.pid") >> + os.remove(self.rootfs_dir + "/log_lock.pid") > Both the description and the code in the patch seem to imply that > sometimes dnf leaves the lock file behind and sometimes it does not. > If that is the case, we need to dig deeper into the reasons why. Yes, sometimes dnf leaves the lock file behind and sometimes it does not. I think it is related to in which condition this dnf issue can be reproduced. I am not very clear about the exact reproduce steps now. That's why existence check is added. Maybe I can take some time to find the step. And a v2 version will be sent. //changqing > > If that is not the case, please change the removal to be deterministic > (remove the existence check), so that it produces an error if the lock > file is not actually left behind by dnf. That way we'll also know when > upstream resolved the issue, if ever. > > Alex
diff --git a/meta/lib/oe/package_manager/rpm/__init__.py b/meta/lib/oe/package_manager/rpm/__init__.py index f40c880af4..bfd40fa691 100644 --- a/meta/lib/oe/package_manager/rpm/__init__.py +++ b/meta/lib/oe/package_manager/rpm/__init__.py @@ -217,6 +217,8 @@ class RpmPM(PackageManager): if len(failed_scriptlets_pkgnames) > 0: failed_postinsts_abort(list(failed_scriptlets_pkgnames.keys()), self.d.expand("${T}/log.do_${BB_CURRENTTASK}")) + self._remove_dnf_lock_file() + def remove(self, pkgs, with_dependencies = True): if not pkgs: return @@ -420,3 +422,7 @@ class RpmPM(PackageManager): os.chdir(current_dir) return tmp_dir + + def _remove_dnf_lock_file(self): + if os.path.exists(self.rootfs_dir + "/log_lock.pid") + os.remove(self.rootfs_dir + "/log_lock.pid")