On Thu, 7 Mar 2024 at 11:21, Chen Qi via lists.openembedded.org
<Qi.Chen=windriver....@lists.openembedded.org> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196785):
https://lists.openembedded.org/g/openembedded-core/message/196785
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]
-=-=-=-=-=-=-=-=-=-=-=-
