Description of problem: The yum backend process hangs indefinitely, while holding a lock on RPM databases and it won't react to SIGTERM. Until the yumBackend.py process gets killed forcibly with SIGKILL, using yum is impossible because a lock is help on the RPM database by yumBackend.py. Strace reports that the process hangs in restart_syscall() function. Version-Release number of selected component (if applicable): PackageKit-0.3.14-1.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1. Wait until packagekit spawns a periodic yum task. 2. Check for the task existence: # pgrep -fl PackageKit 3948 /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py search-file ~installed /lib/firmware/intel-ucode/06-0f-0b 3. Try to kill the task: # kill 3948 # sleep 10 # pgrep -fl PackageKit 3948 /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py search-file ~installed /lib/firmware/intel-ucode/06-0f-0b # pkill -f PackageKit # pgrep -fl PackageKit 3948 /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py search-file ~installed /lib/firmware/intel-ucode/06-0f-0b 4. Strace the process to see where it's stuck: # strace -p 3948 Process 3948 attached - interrupt to quit restart_syscall(<... resuming interrupted call ...>^C <unfinished ...> Process 3948 detached 5. Since the process is frozen, kill it forcibly: kill -9 3948 Actual results: The process never finishes by itself and it can only be terminated using the KILL signal. This can sometimes lead to the corruption of RPM database and a need to run "rpm --rebuilddb", or in extreme cases, "db_recover -e" in /var/lib/rpm/ (if the corruption is recoverable at all). Expected results: yumBackend.py process should under no circumstances hang indefinitely. When received a TERM signal, it should immediately and gracefully terminate operation and free all locks held on the RPM database. Additional info: This occurs in a network environment that requires all HTTP/FTP connections to go through a proxy. Tcpdump shows connection attempts to an external FTP servers - e.g. to port 21 on 85.14.85.4, which resolves to gepard.pbone.net (which is a yum mirror - see ftp://gepard.pbone.net/pub/fedora/pub/fedora/linux/updates/): # dig -x 85.14.85.4 +short gepard.pbone.net. However, adding the proxy configuration to /etc/PackageKit/PackageKit.conf (ProxyHTTP, ProxyFTP) doesn't help. Note that applying the patch from bug 473379 doesn't remedy the situation, so this issue is different.
Changins summary since the problem also exists when proxy is configured.
I changed the version from rawhide to F10 based on the package reported as the problem (PackageKit-0.3.14-1.fc10.x86_64). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Does this work correctly with F11?
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA. -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers