Open kdudka opened 3 months ago
The buggy logic has been deactivated if config_opts['nosync'] = False
(will be in Mock 5.6+) which we think is configured mostly everywhere because nosync is broken. If this is not the case, please tell us.
The problem with the nosync logic is triggered by Mock's locking, and concurrent Mock processes running against the same chroot (e.g. rhel-9-x86_64). When one Mock process performs --init
, the other fails to acquire the lock and expects the chroot has already been initialized.. I'd be surprised if nosync was the only symptom of this concurrency bug.
Thank you for reporting the problem!
@praiskup Thanks for checking! The captured output is from csmock
, which never runs mock
in parallel on the same chroot. csmock
implements its own locking for the whole scans (because csmock
invokes mock
repeatedly for each scan). Anyway, I do not remember when I saw this traceback the last time. And we have not updated mock
on OSH workers since I reported this. So it might have been a bug somewhere else, which has been fixed meanwhile.
An OSH scan of kernel-5.14.0-70.103.1.el9_0
failed with the same traceback yesterday, internally tracked as https://issues.redhat.com/browse/OSH-665. I will try to update mock
to 5.6
in the hope that it will mitigate this issue.
Short description of the problem
mock --init
occasionally fails with a traceback.mock --scrub=root-cache
does not fix it:Output of
rpm -q mock
mock-5.2-1.kdudka.5.el9.noarch
Any additional notes
Output of `mock --debug-config`