Description of problem: PackageKit appears to be stuck when using Apper to Install updates/software. Cause Apper to query endlessly and empty job(s). Version-Release number of selected component (if applicable): PackageKit-0.7.4-4.fc17.x86_64 How reproducible: Everytime Steps to Reproduce: 1. Launch Apper 2. Install updates/software 3. Wait for Apper to finish querying after installing software (querying is endless) 4. While the endless query is occuring there empty job(s) in notification. Actual results: Apper should report software updated etc Expected results: Additional info: Have to kill /usr/libexec/packagekitd to fix issue everytime
It appears that this only occurs when a logout or reboot is required. The Apper update icon remains and the notification job is endless.
I have the same problem: apper becomes irresponsible after updates installation.But restored the ability to start apper after i sent SIGHUP to packagekitd.
(In reply to comment #1) > It appears that this only occurs when a logout or reboot is required. The > Apper update icon remains and the notification job is endless. FYI: Actually it doesn't matter if a reboot or logout is required.
for giggles, I'm testing out adding to /etc/yum.conf: async=False in case that new parallel-download feature is confusing things any.
So, after running ~1 week and doing ~5-10 pk transactions, not a single instance of apper getting stuck using async=False (in /etc/yum.conf) Today, commented out async=False, and the first apper/pk transaction I try, exhibits this bug again. I think we may have found our smoking gun.
while it's stuck this time, here's what pkmon reports: $ pkmon Transactions: [none] daemon connected=1 network status=online Transactions: 1 /2261_caeeaccc_data Transactions: 1 /2261_caeeaccc_data 2 /2262_aeeaddcd_data Transactions: 1 /2261_caeeaccc_data 2 /2262_aeeaddcd_data 3 /2263_dddcdcec_data Transactions: 1 /2261_caeeaccc_data 2 /2262_aeeaddcd_data 3 /2263_dddcdcec_data 4 /2264_eaeecadd_data Transactions: 1 /2261_caeeaccc_data 2 /2262_aeeaddcd_data 3 /2263_dddcdcec_data 4 /2264_eaeecadd_data 5 /2265_ebeeaabc_data Transactions: 1 /2261_caeeaccc_data 2 /2262_aeeaddcd_data 3 /2263_dddcdcec_data 4 /2264_eaeecadd_data 5 /2265_ebeeaabc_data 6 /2266_ecbedecd_data /2261_caeeaccc_data percentage -1 /2261_caeeaccc_data role get-updates /2261_caeeaccc_data status finished /2261_caeeaccc_data exit code: unknown /2262_aeeaddcd_data allow_cancel 1 /2262_aeeaddcd_data percentage -1 /2262_aeeaddcd_data role get-distro-upgrades /2262_aeeaddcd_data status wait /2262_aeeaddcd_data status finished /2262_aeeaddcd_data exit code: unknown /2263_dddcdcec_data allow_cancel 1 /2263_dddcdcec_data percentage -1 /2263_dddcdcec_data role get-updates /2263_dddcdcec_data status wait /2263_dddcdcec_data status finished /2264_eaeecadd_data allow_cancel 1 /2264_eaeecadd_data percentage -1 /2264_eaeecadd_data role get-distro-upgrades /2264_eaeecadd_data status wait /2264_eaeecadd_data status finished /2265_ebeeaabc_data allow_cancel 1 /2265_ebeeaabc_data percentage -1 /2265_ebeeaabc_data role get-updates /2265_ebeeaabc_data status wait /2265_ebeeaabc_data status finished /2266_ecbedecd_data allow_cancel 1 /2266_ecbedecd_data percentage -1 /2266_ecbedecd_data role get-distro-upgrades /2266_ecbedecd_data status wait /2266_ecbedecd_data status finished /2263_dddcdcec_data exit code: unknown /2264_eaeecadd_data exit code: unknown /2265_ebeeaabc_data exit code: unknown /2266_ecbedecd_data exit code: unknown
interesting more just now, while waiting: Transactions: 1 /2261_caeeaccc_data 2 /2262_aeeaddcd_data 3 /2263_dddcdcec_data 4 /2264_eaeecadd_data 5 /2265_ebeeaabc_data 6 /2266_ecbedecd_data 7 /2267_caeceaad_data /2267_caeceaad_data allow_cancel 1 /2267_caeceaad_data percentage -1 /2267_caeceaad_data role get-updates /2267_caeceaad_data status wait /2267_caeceaad_data status finished /2267_caeceaad_data exit code: unknown Transactions: 1 /2261_caeeaccc_data 2 /2262_aeeaddcd_data 3 /2263_dddcdcec_data 4 /2264_eaeecadd_data 5 /2265_ebeeaabc_data 6 /2266_ecbedecd_data 7 /2267_caeceaad_data 8 /2268_aacdaecb_data /2268_aacdaecb_data allow_cancel 1 /2268_aacdaecb_data percentage -1 /2268_aacdaecb_data role get-distro-upgrades /2268_aacdaecb_data status wait /2268_aacdaecb_data status finished /2268_aacdaecb_data exit code: unknown notice the tranactions keep going up 1 each iteration.
oh, I think it's going up by one at least each time I hide/show apper to see it's progress.
Created attachment 594428 [details] test patch, works for me (In reply to comment #5) > So, after running ~1 week and doing ~5-10 pk transactions, not a single > instance of apper getting stuck using > async=False (in /etc/yum.conf) > I think we may have found our smoking gun. Interesting, good work on catching that. Could you try resetting yum.conf to the default, and trying the attached PackageKit patch. You can just copy the lines into /usr/share/PackageKit/helpers/yum/yumBackend.py if you don't fancy rebuilding PK. If that works, I'll do a new upstream release with that fix this week. Thanks.
Cool, patched, tried 2 more pk transactions, so far so good.
This bug will not go away. I did an update via Apper that required a reboot and it would query endlessly plus two phantom jobs would be started. I have async=False (in /etc/yum.conf).
Created attachment 595852 [details] pkmon output
This bug is persistent. I will provide any requested info.
Arg, I wonder if the async thing was a red herring on my part, as now I can see hangs starting again. But, interesting again, only after I re-enabled yum-langpacks (I'd forgotten I'd disabled it awhile back). Kyle (or anyone else still experiencing this), does setting enabled=0 in /etc/yum/pluginconf.d/langpacks.conf help you at all?
Sigh, must be bogons, gremlins or something, see a simple update transaction get stuck afterward even with langpacks disabled today. :-/ $ pkmon Transactions: [none] daemon connected=1 network status=online Transactions: 1 /247_dcebbdac_data Transactions: 1 /247_dcebbdac_data 2 /248_cecbddba_data Transactions: 1 /247_dcebbdac_data 2 /248_cecbddba_data 3 /249_aebaceea_data Transactions: 1 /247_dcebbdac_data 2 /248_cecbddba_data 3 /249_aebaceea_data 4 /250_baadaacd_data /247_dcebbdac_data percentage -1 /247_dcebbdac_data role get-updates /247_dcebbdac_data status finished /247_dcebbdac_data exit code: unknown /248_cecbddba_data allow_cancel 1 /248_cecbddba_data percentage -1 /248_cecbddba_data role get-updates /248_cecbddba_data status wait /248_cecbddba_data status finished /248_cecbddba_data exit code: unknown /249_aebaceea_data allow_cancel 1 /249_aebaceea_data percentage -1 /249_aebaceea_data role get-distro-upgrades /249_aebaceea_data status wait /249_aebaceea_data status finished /250_baadaacd_data allow_cancel 1 /250_baadaacd_data percentage -1 /250_baadaacd_data role get-distro-upgrades /250_baadaacd_data status wait /250_baadaacd_data status finished /249_aebaceea_data exit code: unknown /250_baadaacd_data exit code: unknown
Looks like the patch was committed to PackageKit-yum-0.7.5-1.fc17. Alas, I still have the problem.
I would like to note another side effect of this bug: If Packagekit does not complete it's query the history log in Apper is empty on the date of the transaction under "Details." See attachment.
Created attachment 617696 [details] Apper history
*** Bug 866009 has been marked as a duplicate of this bug. ***
Until the bug is fixed, this is my depressing solution: alias kpk='sudo pkill -f "[pP]ackage[kK]it"'
I'm still seeing this issue on two fully patched Fedora 17 KDE systems. Sometimes after apper has finished installing updates it just hangs with a spinning circle displayed in the window. If I close apper I get the "ghost" job displayed in the notification area. I can cancel the Job, which then gives me a notification "Getting updates [Finished] Job canceled by user" in the notification area. But after logging out and back in the "ghost job reapears and the only way to get rid of it is by killing /usr/libexec/packagekitd. Version-Release number of selected component (if applicable): apper-0.7.2-4.fc17.x86_64 PackageKit-glib-0.7.5-1.fc17.x86_64 PackageKit-0.7.5-1.fc17.x86_64 gnome-packagekit-3.4.2-1.fc17.x86_64 PackageKit-gstreamer-plugin-0.7.5-1.fc17.x86_64 PackageKit-qt-0.7.5-1.fc17.x86_64 PackageKit-device-rebind-0.7.5-1.fc17.x86_64 PackageKit-yum-plugin-0.7.5-1.fc17.x86_64 PackageKit-yum-0.7.5-1.fc17.x86_64 Here's the pkmon output when this happens: # pkmon Transactions: [none] daemon connected=1 network status=online Transactions: 1 /1297_ccaabddb_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data 5 /1301_eeccdcee_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data 5 /1301_eeccdcee_data 6 /1302_ebcaeabd_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data 5 /1301_eeccdcee_data 6 /1302_ebcaeabd_data 7 /1303_bdeaabea_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data 5 /1301_eeccdcee_data 6 /1302_ebcaeabd_data 7 /1303_bdeaabea_data 8 /1304_debcedac_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data 5 /1301_eeccdcee_data 6 /1302_ebcaeabd_data 7 /1303_bdeaabea_data 8 /1304_debcedac_data 9 /1305_baeeeccc_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data 5 /1301_eeccdcee_data 6 /1302_ebcaeabd_data 7 /1303_bdeaabea_data 8 /1304_debcedac_data 9 /1305_baeeeccc_data 10 /1306_ccaceeda_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data 5 /1301_eeccdcee_data 6 /1302_ebcaeabd_data 7 /1303_bdeaabea_data 8 /1304_debcedac_data 9 /1305_baeeeccc_data 10 /1306_ccaceeda_data 11 /1307_aeabbaae_data Transactions: 1 /1297_ccaabddb_data 2 /1298_bebdadca_data 3 /1299_bbbcceec_data 4 /1300_cadcadaa_data 5 /1301_eeccdcee_data 6 /1302_ebcaeabd_data 7 /1303_bdeaabea_data 8 /1304_debcedac_data 9 /1305_baeeeccc_data 10 /1306_ccaceeda_data 11 /1307_aeabbaae_data 12 /1308_acbbbadb_data /1297_ccaabddb_data percentage -1 /1297_ccaabddb_data role get-updates /1297_ccaabddb_data status finished /1298_bebdadca_data allow_cancel 1 /1298_bebdadca_data percentage -1 /1298_bebdadca_data role get-distro-upgrades /1298_bebdadca_data status wait /1298_bebdadca_data status finished /1299_bbbcceec_data allow_cancel 1 /1299_bbbcceec_data percentage -1 /1299_bbbcceec_data role get-updates /1299_bbbcceec_data status wait /1299_bbbcceec_data status finished /1297_ccaabddb_data exit code: unknown /1298_bebdadca_data exit code: unknown /1299_bbbcceec_data exit code: unknown /1300_cadcadaa_data allow_cancel 1 /1300_cadcadaa_data percentage -1 /1300_cadcadaa_data role get-distro-upgrades /1300_cadcadaa_data status wait /1300_cadcadaa_data status finished /1301_eeccdcee_data allow_cancel 1 /1301_eeccdcee_data percentage -1 /1301_eeccdcee_data role get-updates /1301_eeccdcee_data status wait /1301_eeccdcee_data status finished /1302_ebcaeabd_data allow_cancel 1 /1302_ebcaeabd_data percentage -1 /1302_ebcaeabd_data role get-distro-upgrades /1302_ebcaeabd_data status wait /1302_ebcaeabd_data status finished /1303_bdeaabea_data allow_cancel 1 /1303_bdeaabea_data percentage -1 /1303_bdeaabea_data role get-updates /1303_bdeaabea_data status wait /1303_bdeaabea_data status finished /1300_cadcadaa_data exit code: unknown /1301_eeccdcee_data exit code: unknown /1302_ebcaeabd_data exit code: unknown /1303_bdeaabea_data exit code: unknown /1304_debcedac_data allow_cancel 1 /1304_debcedac_data percentage -1 /1304_debcedac_data role get-distro-upgrades /1304_debcedac_data status wait /1304_debcedac_data status finished /1305_baeeeccc_data allow_cancel 1 /1305_baeeeccc_data percentage -1 /1305_baeeeccc_data role refresh-cache /1305_baeeeccc_data status wait /1305_baeeeccc_data status finished /1306_ccaceeda_data allow_cancel 1 /1306_ccaceeda_data percentage -1 /1306_ccaceeda_data role get-updates /1306_ccaceeda_data status wait /1306_ccaceeda_data status finished /1307_aeabbaae_data allow_cancel 1 /1307_aeabbaae_data percentage -1 /1307_aeabbaae_data role get-distro-upgrades /1307_aeabbaae_data status wait /1307_aeabbaae_data status finished /1308_acbbbadb_data allow_cancel 1 /1308_acbbbadb_data percentage -1 /1308_acbbbadb_data role refresh-cache /1308_acbbbadb_data status wait /1308_acbbbadb_data status finished /1304_debcedac_data exit code: unknown /1305_baeeeccc_data exit code: unknown /1306_ccaceeda_data exit code: unknown /1307_aeabbaae_data exit code: unknown /1308_acbbbadb_data exit code: unknown /1309_dbbbbccb_data allow_cancel 1 <<< "ghost" job got cancelled /1309_dbbbbccb_data percentage -1 /1309_dbbbbccb_data role get-updates /1309_dbbbbccb_data status wait /1309_dbbbbccb_data status finished /1310_bdccacee_data allow_cancel 1 /1310_bdccacee_data percentage -1 /1310_bdccacee_data role get-distro-upgrades /1310_bdccacee_data status wait /1310_bdccacee_data status finished /1311_bdcbaeed_data allow_cancel 1 /1311_bdcbaeed_data percentage -1 /1311_bdcbaeed_data role refresh-cache /1311_bdcbaeed_data status wait /1311_bdcbaeed_data status finished /1309_dbbbbccb_data exit code: unknown /1310_bdccacee_data exit code: unknown /1311_bdcbaeed_data exit code: unknown
(In reply to comment #21) > I'm still seeing this issue on two fully patched Fedora 17 KDE systems. > Sometimes after apper has finished installing updates it just hangs with a > spinning circle displayed in the window. If I close apper I get the "ghost" > job displayed in the notification area. I can cancel the Job, which then > gives me a notification "Getting updates [Finished] Job canceled by user" in > the notification area. But after logging out and back in the "ghost job > reapears and the only way to get rid of it is by killing > /usr/libexec/packagekitd. > > Version-Release number of selected component (if applicable): > apper-0.7.2-4.fc17.x86_64 > PackageKit-glib-0.7.5-1.fc17.x86_64 > PackageKit-0.7.5-1.fc17.x86_64 > gnome-packagekit-3.4.2-1.fc17.x86_64 > PackageKit-gstreamer-plugin-0.7.5-1.fc17.x86_64 > PackageKit-qt-0.7.5-1.fc17.x86_64 > PackageKit-device-rebind-0.7.5-1.fc17.x86_64 > PackageKit-yum-plugin-0.7.5-1.fc17.x86_64 > PackageKit-yum-0.7.5-1.fc17.x86_64 > > Here's the pkmon output when this happens: > # pkmon > Transactions: > [none] > daemon connected=1 > network status=online > Transactions: > 1 /1297_ccaabddb_data > Transactions: > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > Transactions: > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > 3 /1299_bbbcceec_data > Transactions: > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > 3 /1299_bbbcceec_data > 4 /1300_cadcadaa_data > Transactions: > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > 3 /1299_bbbcceec_data > 4 /1300_cadcadaa_data > 5 /1301_eeccdcee_data > Transactions: > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > 3 /1299_bbbcceec_data > 4 /1300_cadcadaa_data > 5 /1301_eeccdcee_data > 6 /1302_ebcaeabd_data > Transactions: > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > 3 /1299_bbbcceec_data > 4 /1300_cadcadaa_data > 5 /1301_eeccdcee_data > 6 /1302_ebcaeabd_data > 7 /1303_bdeaabea_data > Transactions: > > 1 /1297_ccaabddb_data > > 2 /1298_bebdadca_data > > 3 /1299_bbbcceec_data > > 4 /1300_cadcadaa_data > > 5 /1301_eeccdcee_data > > 6 /1302_ebcaeabd_data > > 7 /1303_bdeaabea_data > > 8 /1304_debcedac_data > > Transactions: > > 1 /1297_ccaabddb_data > > 2 /1298_bebdadca_data > > 3 /1299_bbbcceec_data > > 4 /1300_cadcadaa_data > > 5 /1301_eeccdcee_data > > 6 /1302_ebcaeabd_data > > 7 /1303_bdeaabea_data > > 8 /1304_debcedac_data > > 9 /1305_baeeeccc_data > > Transactions: > > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > 3 /1299_bbbcceec_data > 4 /1300_cadcadaa_data > 5 /1301_eeccdcee_data > 6 /1302_ebcaeabd_data > 7 /1303_bdeaabea_data > 8 /1304_debcedac_data > 9 /1305_baeeeccc_data > 10 /1306_ccaceeda_data > Transactions: > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > 3 /1299_bbbcceec_data > 4 /1300_cadcadaa_data > 5 /1301_eeccdcee_data > 6 /1302_ebcaeabd_data > 7 /1303_bdeaabea_data > 8 /1304_debcedac_data > 9 /1305_baeeeccc_data > 10 /1306_ccaceeda_data > 11 /1307_aeabbaae_data > Transactions: > 1 /1297_ccaabddb_data > 2 /1298_bebdadca_data > 3 /1299_bbbcceec_data > 4 /1300_cadcadaa_data > 5 /1301_eeccdcee_data > 6 /1302_ebcaeabd_data > 7 /1303_bdeaabea_data > 8 /1304_debcedac_data > 9 /1305_baeeeccc_data > 10 /1306_ccaceeda_data > 11 /1307_aeabbaae_data > 12 /1308_acbbbadb_data > /1297_ccaabddb_data percentage -1 > /1297_ccaabddb_data role get-updates > /1297_ccaabddb_data status finished > /1298_bebdadca_data allow_cancel 1 > /1298_bebdadca_data percentage -1 > /1298_bebdadca_data role get-distro-upgrades > /1298_bebdadca_data status wait > /1298_bebdadca_data status finished > /1299_bbbcceec_data allow_cancel 1 > /1299_bbbcceec_data percentage -1 > /1299_bbbcceec_data role get-updates > /1299_bbbcceec_data status wait > /1299_bbbcceec_data status finished > /1297_ccaabddb_data exit code: unknown > /1298_bebdadca_data exit code: unknown > /1299_bbbcceec_data exit code: unknown > /1300_cadcadaa_data allow_cancel 1 > /1300_cadcadaa_data percentage -1 > /1300_cadcadaa_data role get-distro-upgrades > /1300_cadcadaa_data status wait > /1300_cadcadaa_data status finished > /1301_eeccdcee_data allow_cancel 1 > /1301_eeccdcee_data percentage -1 > /1301_eeccdcee_data role get-updates > /1301_eeccdcee_data status wait > /1301_eeccdcee_data status finished > /1302_ebcaeabd_data allow_cancel 1 > /1302_ebcaeabd_data percentage -1 > /1302_ebcaeabd_data role get-distro-upgrades > /1302_ebcaeabd_data status wait > /1302_ebcaeabd_data status finished > /1303_bdeaabea_data allow_cancel 1 > /1303_bdeaabea_data percentage -1 > /1303_bdeaabea_data role get-updates > /1303_bdeaabea_data status wait > /1303_bdeaabea_data status finished > /1300_cadcadaa_data exit code: unknown > /1301_eeccdcee_data exit code: unknown > /1302_ebcaeabd_data exit code: unknown > /1303_bdeaabea_data exit code: unknown > /1304_debcedac_data allow_cancel 1 > /1304_debcedac_data percentage -1 > /1304_debcedac_data role get-distro-upgrades > /1304_debcedac_data status wait > /1304_debcedac_data status finished > /1305_baeeeccc_data allow_cancel 1 > /1305_baeeeccc_data percentage -1 > /1305_baeeeccc_data role refresh-cache > /1305_baeeeccc_data status wait > /1305_baeeeccc_data status finished > /1306_ccaceeda_data allow_cancel 1 > /1306_ccaceeda_data percentage -1 > /1306_ccaceeda_data role get-updates > /1306_ccaceeda_data status wait > /1306_ccaceeda_data status finished > /1307_aeabbaae_data allow_cancel 1 > /1307_aeabbaae_data percentage -1 > /1307_aeabbaae_data role get-distro-upgrades > /1307_aeabbaae_data status wait > /1307_aeabbaae_data status finished > /1308_acbbbadb_data allow_cancel 1 > /1308_acbbbadb_data percentage -1 > /1308_acbbbadb_data role refresh-cache > /1308_acbbbadb_data status wait > /1308_acbbbadb_data status finished > /1304_debcedac_data exit code: unknown > /1305_baeeeccc_data exit code: unknown > /1306_ccaceeda_data exit code: unknown > /1307_aeabbaae_data exit code: unknown > /1308_acbbbadb_data exit code: unknown > /1309_dbbbbccb_data allow_cancel 1 <<< "ghost" job got > cancelled > /1309_dbbbbccb_data percentage -1 > /1309_dbbbbccb_data role get-updates > /1309_dbbbbccb_data status wait > /1309_dbbbbccb_data status finished > /1310_bdccacee_data allow_cancel 1 > /1310_bdccacee_data percentage -1 > /1310_bdccacee_data role get-distro-upgrades > /1310_bdccacee_data status wait > /1310_bdccacee_data status finished > /1311_bdcbaeed_data allow_cancel 1 > /1311_bdcbaeed_data percentage -1 > /1311_bdcbaeed_data role refresh-cache > /1311_bdcbaeed_data status wait > /1311_bdcbaeed_data status finished > /1309_dbbbbccb_data exit code: unknown > /1310_bdccacee_data exit code: unknown > /1311_bdcbaeed_data exit code: unknown It doesn't look promising that this bug will be fixed. It's a stinky bug.
I was trying to debug this issue some time ago, but didn't come up to a definite result because I'm not very familiar with glib and its event loop mechanics. What I found was looking like some kind of flaw in the way PackageKit detects whether session or system has to be restarted after package update. The plugin responsible for that is in "src/plugins/pk-plugin-check-shared-libraries-in-use.c" source file of PackageKit. The simplified logic of this plugin looks like this. * Given a list of shared libraries being updated, the list of PIDs of running processes using these shared libraries is obtained using lsof. * For each PID: - "/proc/$PID/cmdline" is read, command name is taken from there; - If command name does not start with "/", "/usr/bin/" prefix is prepended; - yumBackend.py is started to determine the package the command belongs to. The bug is in the way command name is obtained. It should readlink "/proc/$PID/exe" instead of reading contents of "/proc/$PID/cmdline" because comand line can be mangled by the process, and some programs do it extensively. Also, assuming that all programs run with relative pathnames reside in "/usr/bin" is wrong as well. I'm not sure whether this bug is the root cause or not, but what I was observing is packagekitd stuck in g_main_loop_run() inside pk_plugin_get_installed_package_for_file() finction, having a funny string "/usr/bin/-:0" in filename variable. The way PackageKit uses "/proc/$PID/cmdline" to obtain executable file's pathname is definitely a bug. However, I presume, the root cause must be another bug in the way results of yumBackend.py are parsed which lead to event loop to be stuck in case file doesn't belong to any package, and this bug is just triggered by the first bug when mangled cmdline is encountered. If my guess is right, even if the first bug is fixed, the second one may be triggered by updating a shared library which is used by some program not belonging to any package. Also, if my guess is right, it may explain why this bug is observable so rarely and on a very few systems. To trigger this bug two conditions have to be met: - lsof must be already installed in system (otherwise all logic of PID detection does not work), - a shared library used by a program mangling its cmdline (like sendmail, kdm) should be updated.
This seems to only happen with longer updates. If I only have one or two packages to update, then it seems to finish properly. If there are more, it will hang after the update finishes. Perhaps there is an issue if an update check happens while an update is being done.
I'm no seeing this issue on two F17 systems almost every time I'm using Apper to install updates, even if it only has to install one or two updates. So I wouldn't call this a rarely observable bug.
Yeah, same here (on my F17 machine), su -c "killall packagekitd" has become part of my daily update routine. :-(
I haven't seen any of these problems since updating to F18.
Setting async=False helped me on the first try. Before that I tried killing packagekitd several times but it only released apper and when I pressed the update picture it hung again and again.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.