Bug 487321 - packagekit/yumBackend.py hangs if direct HTTP/FTP connections are blocked
packagekit/yumBackend.py hangs if direct HTTP/FTP connections are blocked
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
10
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-25 09:03 EST by Aleksander Adamowski
Modified: 2009-09-07 22:04 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-07 22:04:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksander Adamowski 2009-02-25 09:03:56 EST
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.
Comment 1 Aleksander Adamowski 2009-02-25 09:07:10 EST
Changins summary since the problem also exists when proxy is configured.
Comment 2 TK009 2009-03-03 20:00:12 EST
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
Comment 3 Richard Hughes 2009-06-03 05:00:05 EDT
Does this work correctly with F11?
Comment 4 Steven M. Parrish 2009-09-07 22:04:37 EDT
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

Note You need to log in before you can comment on or make changes to this bug.