Description of problem: Todays 'dnf upgrade' seems to have lots of problem with dnf. So where am I now - Upgrading : wine-arial-fonts-1.7.43-1.fc23.noarch 276/1108 Upgrading : vte-profile-0.40.2-1.fc23.x86_64 277/1108 Upgrading : vte291-0.40.2-1.fc22.x86_64 278/1108 Upgrading : perl-HTTP-Tiny-0.056-1.fc23.noarch 279/1108 Upgrading : mesa-filesystem-10.6.0-0.devel.6.5a55f68.fc23.x86_64 280/1108 Upgrading : man-pages-4.00-1.fc23.noarch 281/1108 **Waiting here** forever? TOP shows nothing: %Cpu(s): 4,8 us, 1,3 sy, 0,0 ni, 93,7 id, 0,2 wa, 0,0 hi, 0,0 si, 0,0 st Everything in idle (except for mozilla browser). pstree: bash---su---bash---dnf Nothing forked from 'dnf' - so it sleeps INSIDE dnf. Is this 'dnf' tested before being pushed to rawhide? (glad we still have at least yum-deprecated) I wanted to attach 'gdb' to python - but with no success - freezed as well. Thus the only thing I could see is from strace: futex(0x7f00cf75f624, FUTEX_WAIT, 1 Here is kernel stacktrace: dnf S ffff880078d87c28 0 15769 10479 0x00000080 ffff880078d87c28 ffff880078c44590 ffff8800677327c0 ffffc9000066cac8 ffff880078d87fd8 ffff8800677327c0 0000000000000000 ffffc9000066cac0 ffff880078d87d00 ffff880078d87c48 ffffffff81783f77 ffffc9000066cac0 Call Trace: [<ffffffff81783f77>] schedule+0x37/0x90 [<ffffffff811174e8>] futex_wait_queue_me+0xc8/0x140 [<ffffffff811177a9>] futex_wait+0x119/0x290 [<ffffffff810ab372>] ? get_signal+0xf2/0x610 [<ffffffff81119c55>] do_futex+0x145/0xab0 [<ffffffff81013547>] ? do_signal+0x37/0x760 [<ffffffff810ab24b>] ? ptrace_notify+0x5b/0x90 [<ffffffff81022e56>] ? tracehook_report_syscall_exit+0xd6/0x120 [<ffffffff8111a641>] SyS_futex+0x81/0x190 [<ffffffff810238db>] ? syscall_trace_enter_phase1+0x14b/0x1b0 [<ffffffff81013cef>] ? do_notify_resume+0x7f/0xa0 [<ffffffff81788089>] system_call_fastpath+0x12/0x17 I really think such important package like 'dnf' needs some testing before it lands even in rawhide - 'we don't care what happens - it's rawhide, it's your fault you are using it' is really a wrong way here... Version-Release number of selected component (if applicable): dnf-1.0.0-1.fc23.noarch How reproducible: Steps to Reproduce: 1. dnf upgrade (for rawhide on 2015-05-21) 2. 3. Actual results: Expected results: Additional info:
Created attachment 1028180 [details] lsof | grep dnf Possibly dnf died because it has been upgraded in the middle of execution ? Is 'dnf' trying to convince user they need to upgrade in 'special' environment.
So as a great bonus after 'killing' dnf process (since nothing else was helpful) I'm left with wonderful rpm DB state: # LC_ALL=C rpm -qa error: rpmdb: BDB0113 Thread/process 18156/140297016870656 failed: BDB1507 Thread died in Berkeley DB library error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in /var/lib/rpm error: rpmdb: BDB0113 Thread/process 18156/140297016870656 failed: BDB1507 Thread died in Berkeley DB library error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in /var/lib/rpm
Zdenek, can you upload `/var/log/dnf.log`, please, so we can try to reproduce it with the same package set? Still I think the most probably it was caused by some scriplet or the error inside RPM process. Post the `rpm -q rpm` too. Thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
I talked to Zdenek via IRC and unfortunately the log were rotated. I am sorry but we can;t reproduce it and didn't know the cause.