Created attachment 327160 [details] segfault of the funcd daemon Description of problem: On F10, the func modules which try to use the rpm-python moudule (rpms and yummodule) cause the funcd process to segfault. Version-Release number of selected component (if applicable): func-0.24 (git version ) [root@localhost lib]# rpm -q rpm rpm-python gnupg python rpm-4.6.0-0.rc1.8.i386 rpm-python-4.6.0-0.rc1.8.i386 gnupg-1.4.9-4.fc10.i386 python-2.5.2-1.fc10.i386 How reproducible: I can reproduce it reliably. Steps to Reproduce: At the moment, I don't have a non func reproducer case, but 1. install func from git 2. run `func "*" call rpms inventory` 3. funcd process that handles the request segfaults, and a weird error propagates back to the func client (it seems to manifest itself as an openssl error, but thats due to the poor handling of the segfault error) Actual results: Expected results: Additional info: The system in question was updated from f9 via preupgrade. The system had been previously updated from F-8, and maybe earlier. There were several gpg keys in the database, even though it doesn't seem to matter which ones. Removing all of them seems to make the error go away. I have a copy of my rpm database in the state that was causing the segfaults if it is needed. A stack trace is attached.
Not sure it was clear in the initial description, but the funcd process is of a multi process type, so that may be an issue (since it doesn't seem to happen in yum/rpm).
Ok, the fundamental issue is that NSS doesn't like forks after initialization. Rpm initializes NSS at the earliest possible moment to avoid other issues (as on the other hand, NSS needs to be initialized before chroot), which in case of python is rpm module load time. In func, this happens at funcd startup due to loading the minion modules, although any rpm functionality will only be used in a separate process/thread created if/when rpms/yumcmds is called. The same issue is present on F8/F9 (where rpm 4.4.2.x is patched to use NSS) too, it's just pretty well hidden there: once forked after initialization, header checking on the db will show "signature: NOKEY" (when it should be "signature: OK") but this is only visible in debug level messages. Seems like I'm in for some NSS-studying to figure how to best deal with this in rpm. Meanwhile, it can be worked around by loading the rpm module only after fork, will attach a patch shortly.
Created attachment 327324 [details] Workaround patch This works around the issue by delaying rpm (and yum) module loading until the last minute so the initialization will happen in the new process context.
Fixed upstream now: a) dont crash even if NSS isn't functional b) delay NSS initialization until actually needed
Should be fixed in rawhide as of rpm-4.6.0-0.rc4.1.fc11, F10 obviously needs an update soon too.
rpm-4.6.0-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rpm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1478
Panu, any chance this can make it back to f9?
*** Bug 472270 has been marked as a duplicate of this bug. ***
*** Bug 483412 has been marked as a duplicate of this bug. ***
*** Bug 480071 has been marked as a duplicate of this bug. ***
*grumble* Seems like I have to (there's a pile of various misc fixes that F9 wants too so there's going to be an update anyway sooner or later). This tracks F10 though, would've been better to leave one of the F9-specific ones open separately for tracking purposes.
The work around patch doesn't seem to working very well. yumcmds and rpms module still fail if they try to run a transaction. Stacktrace looks more or less the same as the one previously posted. Trying to track this down some more.
On closer inspection, ignore #12. Seems to be working once I get all the junk out of my devel tree.
rpm-4.6.0-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.