On 3/7/24 19:42, 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 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
This issue only happened when dnf log rotate is happened. maybe install
"a lot" packages can trigger reproduce this issue more quickly.
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()
Hi,
Thanks for trying to help. I had try to find the root cause when I
opened the upstream issue, but unfortunately, not got the root cause, I
thought
it should be a complicated one. After do more investigating recently,
the root cause should be found, and I have send pull request [1] to
upsteam dnf ,
will backport the patch if upstream accept the fix.
[1] https://github.com/rpm-software-management/dnf/pull/2065
//Changqing
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197122):
https://lists.openembedded.org/g/openembedded-core/message/197122
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]]
-=-=-=-=-=-=-=-=-=-=-=-
