Hi Alex, You can see dnf's solution is: https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf
I don't think dnf community will look into this issue. And I would expect it to be a complicated one. Because dnf's own solution looks like more of a workaround. At the same time, yocto based systems will sometimes have log_lock.pid left in target filesystems. Users typing 'ls /' will notice it. We have an OE specific patch: https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66 I can see that this OE specific patch, 0001-dnf-write-the-log-lock-to-root.patch, does solve some issue. Unfortunately, at the same time, it introduces this specific issue, a easy-to-notice one. My suggestion is that we merge this fix into 0001-dnf-write-the-log-lock-to-root.patch, because they really belong together. I guess we can't expect dnf community to devote time into this, as they've already got a solution. And I'm not sure if anyone in OE community is familiar with dnf enough to solve this issue. So let's make things a little better, avoiding users of Yocto systems see this log_lock.pid file when they type 'ls /'. If you have any other suggestion, please let us know. Regards, Qi -----Original Message----- From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Alexander Kanavin via lists.openembedded.org Sent: Thursday, March 7, 2024 5:57 PM To: Li, Changqing <changqing...@windriver.com>; Richard Purdie <richard.pur...@linuxfoundation.org> Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH V2] dnf: remove log_lock.pid before exit On Thu, 7 Mar 2024 at 10:19, Changqing Li <changqing...@eng.windriver.com> wrote: > ++ for arg in args: > ++ if arg.startswith("--installroot="): > ++ root=arg.split("=")[1] > ++ if os.path.exists(os.path.join(root, "log_lock.pid")): > ++ os.unlink(os.path.join(root, "log_lock.pid")) > ++ break Apologies, but after looking at this more carefully I have to say no once more. The obstacle is that the code checks for existence before removing the lock, which means the issue of why the lock is left in place to begin with is still unresolved. This doesn't always happen, and we need to get to the bottom of *why*. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196784): https://lists.openembedded.org/g/openembedded-core/message/196784 Mute This Topic: https://lists.openembedded.org/mt/104784184/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
