Bug 585755 - yum update hangs by updating hpijs.
Summary: yum update hangs by updating hpijs.
Alias: None
Product: Fedora
Classification: Fedora
Component: hplip
Version: 12
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-25 22:56 UTC by sjoerd
Modified: 2010-06-17 03:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-06-17 03:06:21 UTC
Type: ---

Attachments (Terms of Use)

Description sjoerd 2010-04-25 22:56:26 UTC
Description of problem:
Yum updating hpijs hangs on running hpcups-update-ppds

28437 pts/0    S+     0:00 /bin/bash /usr/bin/hpcups-update-ppds
28441 pts/0    S+     0:00 lpstat -h /var/run/cups/cups.sock -p Cups-PDF

Last excerpt from yum update:
Updating: 1:nfs-utils-1.2.1-5.fc12.x86_64    18/50 
Updating: hplip-common-3.10.2-6.fc12.x86_64  19/50 
Updating: hplip-libs-3.10.2-6.fc12.x86_64    20/50 
Updating: libsane-hpaio-3.10.2-6.fc12.x86_64 21/50 
Updating: 1:hpijs-3.10.2-6.fc12.x86_64       22/50

Version-Release number of selected component (if applicable):

How reproducible:
Dunno. Still hangs after 2 hours of this writing.

Steps to Reproduce:
1. yum update hpijs?
Actual results:
hpijs gets installed

Expected results:

Additional info:
# cat /var/tmp/rpm-tmp.YwrQT7
/usr/bin/hpcups-update-ppds &>/dev/null ||:

# uname -r

# rpm -qa *PyQt*

Comment 1 sjoerd 2010-04-25 23:07:19 UTC

Actual results:
hpijs install hangs forever

Expected results:
hpijs gets installed

Comment 2 sjoerd 2010-04-26 00:19:44 UTC

killing the avahi-daemon process, witch went 100% cpu, solves this hang and yum update finally updates all the latest packages.

  ModemManager.x86_64 0:0.3-9.git20100409.fc12          NetworkManager.x86_64 1:0.8.0-6.git20100408.fc12      
  NetworkManager-glib.x86_64 1:0.8.0-6.git20100408.fc12 NetworkManager-gnome.x86_64 1:0.8.0-6.git20100408.fc12
  abrt.x86_64 0:1.0.9-1.fc12                            abrt-addon-ccpp.x86_64 0:1.0.9-1.fc12                 
  abrt-addon-kerneloops.x86_64 0:1.0.9-1.fc12           abrt-addon-python.x86_64 0:1.0.9-1.fc12               
  abrt-desktop.x86_64 0:1.0.9-1.fc12                    abrt-gui.x86_64 0:1.0.9-1.fc12                        
  abrt-libs.x86_64 0:1.0.9-1.fc12                       abrt-plugin-bugzilla.x86_64 0:1.0.9-1.fc12            
  abrt-plugin-logger.x86_64 0:1.0.9-1.fc12              abrt-plugin-runapp.x86_64 0:1.0.9-1.fc12              
  hpijs.x86_64 1:3.10.2-6.fc12                          hplip.x86_64 0:3.10.2-6.fc12                          
  hplip-common.x86_64 0:3.10.2-6.fc12                   hplip-gui.x86_64 0:3.10.2-6.fc12                      
  hplip-libs.x86_64 0:3.10.2-6.fc12                     libgudev1.x86_64 0:145-20.fc12                        
  libsane-hpaio.x86_64 0:3.10.2-6.fc12                  libudev.x86_64 0:145-20.fc12                          
  nfs-utils.x86_64 1:1.2.1-5.fc12                       udev.x86_64 0:145-20.fc12                             
  xorg-x11-drv-wacom.x86_64 0:0.10.5-1.fc12            


Comment 3 Tim Waugh 2010-04-26 08:07:23 UTC
That's weird.

Can you find any logged messages in /var/log/messages about why avahi-daemon was so busy?  Or cupsd, for that matter?

hpcups-update-ppds calls lpstat, which sends a request to cupsd and waits for a response.  It looks like we just didn't get a response for ages.  But cupsd itself doesn't talk to avahi, only the dnssd backend does -- and there's no reason that should even have been running.  So avahi-daemon being at 100% CPU doesn't really explain enough about what went wrong. :-(

Comment 4 sjoerd 2010-04-26 18:51:10 UTC
I don't have much more info. Some lines from /var/log/messages:

Apr 26 02:12:28 asus avahi-dnsconfd[16293]: read(): EOF
Apr 26 02:12:35 asus yum: Updated: 1:hpijs-3.10.2-6.fc12.x86_64
Apr 26 02:12:40 asus yum: Updated: hplip-3.10.2-6.fc12.x86_64
Apr 26 02:12:47 asus ntpd[14103]: Deleting interface #10 pan0:avahi,, interface stats: receiv
ed=0, sent=0, dropped=0, active_time=159058 secs

I could'n simply stop the avahi-daemon in the normal manner by entering *service avahi-daemon stop* this command didn't work due to a timeout.

I had to kill the daemon with the *kill -9 <pid>* command to shut it down hence the last ntpd line in the log.

Maybe it isn't an hpijs bug but aan avahi bug. I don't no.

Btw. There wasn't any more info in the cups logs.

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