Bug 487321

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.