Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

log_lock.pid cannot be deleted #1963

Open
sandy-lcq opened this issue Jul 11, 2023 · 0 comments
Open

log_lock.pid cannot be deleted #1963

sandy-lcq opened this issue Jul 11, 2023 · 0 comments
Labels
Priority:LOW triaged

Comments

@sandy-lcq
Copy link

sandy-lcq commented Jul 11, 2023 •
edited

Version:
dnf 4.14.0

Reproduce steps:
NOTE: I am using yocto project to build an image, which will using dnf to install some packages under rootfs. You
can see my attached log to see what it has done.

  1. clean build, see log.do_rootfs.1.txt, count of ProcessLock all changed to 0, so log_lock.pid is unlinked
  2. rebuild(change the packages installed to rootfs), see log.do_rootfs.2.txt, seems when there is log rotate, count of ProcessLock cannot changed to 0, so log_lock.pid is not unlinked. it is still there even after the build completed.
    $ cat log_lock.pid
    4053726

And I checked by ps command during build, pid 4053726 is the command in Line 42 of log log.do_rootfs.2.txt. And I checked that after build completed, there is no hanging dnf, all exited normally.

Seems like handling of "count of ProcessLock" is not proper. I add some debug message to the dnf, see 0001-debug.patch.txt.
maybe can help to debug this issue. You can see it from the log.

log.do_rootfs.1.txt

log.do_rootfs.2.txt

0001-debug.patch.txt
@sandy-lcq sandy-lcq changed the title sometimes, log_lock.pid cannot be deleted log_lock.pid cannot be deleted Jul 11, 2023
@pkratoch pkratoch removed their assignment Jul 24, 2023
sandy-lcq added a commit to sandy-lcq/dnf that referenced this issue Mar 13, 2024
@sandy-lcq
lock.py: fix Exception handling
3881757 
Before, when logdir is not writable, _try_lock will raise an Exception
like "Permission denied: '/var/log/log_lock.pid'", and in this case,
_unlock_thread will not be called and the variable count will not be
handled, it maybe cause log_lock.pid not be deleted in case like [1].

For [1], it is an cross compile case, when dnf install some packages to
rootfs, seems like some threads don't do chroot like work, some threads
do chroot like work. so for the threads don't do chroot, "Permission denied"
Exception happend, for the threads that do chroot, log_lock.pid will be
created under installroot/var/log/log_lock.pid, since variable count not
handled correct before, log_lock.pid may not be deleted correctly.

So fixed like this, if _try_lock raise Exception, _unlock_thread first,
then raise the Exception.

[1] rpm-software-management#1963

Signed-off-by: Changqing Li <changqing.li@windriver.com>
@sandy-lcq sandy-lcq mentioned this issue Mar 13, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Priority:LOW triaged
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pkratoch @sandy-lcq