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.

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

lock.py: fix Exception handling #2065

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sandy-lcq
Copy link

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] #1963

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 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant