> -----Original Message----- > From: [email protected] <openembedded- > [email protected]> On Behalf Of Alexander Kanavin > Sent: den 7 mars 2024 12:42 > To: [email protected] > Cc: Li, Changqing <[email protected]>; Richard Purdie > <[email protected]>; openembedded- > [email protected] > Subject: Re: [OE-core] [PATCH V2] dnf: remove log_lock.pid before exit > > On Thu, 7 Mar 2024 at 11:21, Chen Qi via lists.openembedded.org > <[email protected]> wrote: > > 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. > > We need to find out why it happens, and why it happens only sometimes. > If lock file does not get properly deleted that is quite possibly > masking a different issue which needs fixing, and the proposed patch > just sweeps it all under the carpet in the name of giving users an > aesthetically pleasing rootfs. So the answer is still no. > > If you are having difficulty debugging the situation where the lock > file does get left behind, can you provide a way for me to reproduce > the issue? I just build core-image-minimal, and I'm not seeing it: > > alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ls > tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/rootfs/ > bin boot dev etc home lib media mnt proc root run sbin srv > sys tmp usr var > > If you can't provide that, then you can certainly still do more on > your side: build core-image-minimal with plain poky, ensure the lock > file gets deleted, then build your own private things where the file > does not get deleted, then investigate why the code path that deletes > the lock file isn't being taken in the latter case. You can see the > code where the lock log (self.rotate_lock) is used in logging.py: > > def emit(self, record): > while True: > try: > if self.shouldRollover(record): > with self.rotate_lock: > # Do rollover while preserving the mode of the new > log file > mode = os.stat(self.baseFilename).st_mode > self.doRollover() > os.chmod(self.baseFilename, mode) > logging.FileHandler.emit(self, record) > return > except (dnf.exceptions.ProcessLockError, > dnf.exceptions.ThreadLockError): > time.sleep(0.01) > except Exception: > self.handleError(record) > return > > And the deletion happens in lock.py: > > def __exit__(self, *exc_args): > if self.count == 1: > os.unlink(self.target) > self._unlock_thread() > > > > Alex
I did try to find a solution to this problem quite a while back, but unfortunately never managed to get to the bottom of it. What I did figure out was that the problem is related to whether dnf thinks it is running as root or not as that results in different paths being used. I.e., it may create the file in one place and then try to delete it in another. What I never could figure out is how/where dnf switches between root/not root as it seems to happen mid-run. //Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196795): https://lists.openembedded.org/g/openembedded-core/message/196795 Mute This Topic: https://lists.openembedded.org/mt/104784184/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
