Bug#840327: stopped working, no helpful feedback
On Tue 11 Oct 2016 at 12:19:30 +0200, Daniel Pocock wrote: > >> On 10/10/16 21:22, Brian Potkin wrote: > > > > My view would be that with printing problems users have to be prepared > > to dig into log files, particularly the error_log. Without it a user > > will get nowhere -fast. > > > > [...Snip...] > > In that case, we really need to anticipate having a GUI for browsing > SysLog in the default desktop. Text based log files are not great for > the average user and even for power users, the text-based log files > don't distinguish errors from warnings or info messages. As promised: https://wiki.debian.org/Dissecting%20and%20Debugging%20the%20CUPS%20Printing%20System#Problems_with_mdns.2FDNS-SD It will eventually be linked to from a forthcoming hplip page/section and perhaps from elsewhere. IMO, there is no bug of any description in cups or hplip; that does not mean the error messages in logs are clearly understandable or cover all possible causes of failure. An all-encompassing GUI to browse text logs and make them understandable on all levels to all users is well beyond the resources and remit of the printing framework; a Debian-wide effort would be necessary. Perhaps opening a discussion on -devel would lead to a consensus? (Ever since the beginning of this report I have been intrigued by the ABC123DEF.local in the daemon.log. I assume you used hp-setup; hp-setup discovers printers on the network, not print queues, and I've only seen HPXX or NXXX in the device_uri. The LaserJet 3055 does AirPrint so I suppose you altered this from the printer's web interface? Just curious; it all adds to the store of knowledge :) ). Cheers, Brian.
Bug#840327: stopped working, no helpful feedback
On Tue 11 Oct 2016 at 12:19:30 +0200, Daniel Pocock wrote: > On 11/10/16 12:02, Brian Potkin wrote: > > [I made a mistake with my previous mail by not sending it to the BTS. > > Because of that your reply didn't go there either. I've rectified the > > bug record by bouncing both mails to the BTS and setting the addresses > > correctly on this mail]. > > > > > > On Tue 11 Oct 2016 at 09:59:42 +0200, Daniel Pocock wrote: > > > >> On 10/10/16 21:22, Brian Potkin wrote: > >>> > >>> Printing "working fine" for a long time must indicate something to you. > >>> Then it stops working. How is this a bug rather than a matter for > >>> debian-user? Computer systems don't generally go into meltdown because > >>> they feel unappreciated. > >> > >> The bug isn't because it stopped working (I got it working again anyway) > >> > >> I raised a bug because I was hoping we could improve the user experience > >> for people who don't know how to dig around in the log files. Maybe it > >> should be a wishlist bug. > > > > My view would be that with printing problems users have to be prepared > > to dig into log files, particularly the error_log. Without it a user > > will get nowhere -fast. > > > > [...Snip...] > > > > In that case, we really need to anticipate having a GUI for browsing > SysLog in the default desktop. Text based log files are not great for > the average user and even for power users, the text-based log files > don't distinguish errors from warnings or info messages. GUIs for browsing any logs is a much wider issue than what we have here. The primary source of information for diagnosing problems with the printing system is the error_log. It has good discrimination indicators for error, info etc. I believe Fedora feed it to journalctl so I suppose you get colour too! > >>> This is a symptom indicating you have done something to the system. It > >>> never happened before; why should it happen now? Things don't generally > >>> occur out of the blue. > >> > >> After looking more closely, I believe the root cause was a recent > >> firewall change that was interfering with mDNS. Tweaking the firewall > >> makes it work again. This hadn't been obvious because some other > >> devices had been able to send stuff to the printer and the printer and > >> the printer's web admin pages were accessible. > > > > Is it possible to be a little more specific about the firewall settings > > which blocked mDNS packets? I think that on Fedora SELinux is there by > > default and it is not unknown for it to cause a misconfiguration issue > > such as the one you have experienced. However, I have not seen it on > > Debian so knowing what you did would be a useful jumping off point for > > documentation. > > In this case, Shorewall had been installed with a very basic configuration > > Adding this entry to /etc/shorewall/rules in SECTION NEW: > > > > SECTION NEW > > mDNS(ACCEPT) loc fw > > > > made it work. Thank you for this; it gives me something to work on. Incidentally, hp-setup GUI and hp-probe suggest examining firewall settings if a printer is not detected. Cheers, Brian.
Bug#840327: stopped working, no helpful feedback
On Tue 11 Oct 2016 at 11:20:48 +0200, Daniel Pocock wrote: > On 11/10/16 10:16, Brian Potkin wrote: > > > > Please do > > > > avahi-browse -art > filename > > > > and post filename. avahi-browse is in the avahi-utils package. > > > > Also post the outputs of > > > > /usr/sbin/lpinfo -v > > /usr/lib/cups/backend/snmp > > ping -c3 ABC123DEF.local > > > > I found out that the root cause appeared to be a firewall change that > was specifically blocking the mDNS stuff while other things still > worked, I commented on it in this reply on debian-printing: > > https://lists.debian.org/debian-printing/2016/10/msg00079.html Yes, I saw that. Glad you sorted it. > Is there anything the avahi tools can do in scenarios like this to > provide more information through the printing diagnostic wizard? I asked for the information above for a purpose. Apart from providing a diagnostic for your now solved problem it would help to improve the present documentation. It would still be useful to have. Cheers, Brian.
Bug#840327: stopped working, no helpful feedback
On 11/10/16 12:02, Brian Potkin wrote: > [I made a mistake with my previous mail by not sending it to the BTS. > Because of that your reply didn't go there either. I've rectified the > bug record by bouncing both mails to the BTS and setting the addresses > correctly on this mail]. > > > On Tue 11 Oct 2016 at 09:59:42 +0200, Daniel Pocock wrote: > >> On 10/10/16 21:22, Brian Potkin wrote: >>> >>> Printing "working fine" for a long time must indicate something to you. >>> Then it stops working. How is this a bug rather than a matter for >>> debian-user? Computer systems don't generally go into meltdown because >>> they feel unappreciated. >> >> The bug isn't because it stopped working (I got it working again anyway) >> >> I raised a bug because I was hoping we could improve the user experience >> for people who don't know how to dig around in the log files. Maybe it >> should be a wishlist bug. > > My view would be that with printing problems users have to be prepared > to dig into log files, particularly the error_log. Without it a user > will get nowhere -fast. > > [...Snip...] > In that case, we really need to anticipate having a GUI for browsing SysLog in the default desktop. Text based log files are not great for the average user and even for power users, the text-based log files don't distinguish errors from warnings or info messages. >>> This is a symptom indicating you have done something to the system. It >>> never happened before; why should it happen now? Things don't generally >>> occur out of the blue. >> >> After looking more closely, I believe the root cause was a recent >> firewall change that was interfering with mDNS. Tweaking the firewall >> makes it work again. This hadn't been obvious because some other >> devices had been able to send stuff to the printer and the printer and >> the printer's web admin pages were accessible. > > Is it possible to be a little more specific about the firewall settings > which blocked mDNS packets? I think that on Fedora SELinux is there by > default and it is not unknown for it to cause a misconfiguration issue > such as the one you have experienced. However, I have not seen it on > Debian so knowing what you did would be a useful jumping off point for > documentation. > In this case, Shorewall had been installed with a very basic configuration Adding this entry to /etc/shorewall/rules in SECTION NEW: SECTION NEW mDNS(ACCEPT) loc fw made it work.
Bug#840327: stopped working, no helpful feedback
[I made a mistake with my previous mail by not sending it to the BTS. Because of that your reply didn't go there either. I've rectified the bug record by bouncing both mails to the BTS and setting the addresses correctly on this mail]. On Tue 11 Oct 2016 at 09:59:42 +0200, Daniel Pocock wrote: > On 10/10/16 21:22, Brian Potkin wrote: > > > > Printing "working fine" for a long time must indicate something to you. > > Then it stops working. How is this a bug rather than a matter for > > debian-user? Computer systems don't generally go into meltdown because > > they feel unappreciated. > > The bug isn't because it stopped working (I got it working again anyway) > > I raised a bug because I was hoping we could improve the user experience > for people who don't know how to dig around in the log files. Maybe it > should be a wishlist bug. My view would be that with printing problems users have to be prepared to dig into log files, particularly the error_log. Without it a user will get nowhere -fast. [...Snip...] > > This is a symptom indicating you have done something to the system. It > > never happened before; why should it happen now? Things don't generally > > occur out of the blue. > > After looking more closely, I believe the root cause was a recent > firewall change that was interfering with mDNS. Tweaking the firewall > makes it work again. This hadn't been obvious because some other > devices had been able to send stuff to the printer and the printer and > the printer's web admin pages were accessible. Is it possible to be a little more specific about the firewall settings which blocked mDNS packets? I think that on Fedora SELinux is there by default and it is not unknown for it to cause a misconfiguration issue such as the one you have experienced. However, I have not seen it on Debian so knowing what you did would be a useful jumping off point for documentation. [...Another snip...] > > System administrators should always feel comfortable about trouble > > shooting. Admit it; you really love log files. :) > > If I love log files, why would I have packaged LogAnalyzer[1] ? That was the point of my remark. :) > As I mentioned earlier, I opened the bug report to see if there is > anything we can do to make this easier for people who are not sysadmins > or DDs. I had a colleague who saw somebody throw a printer across an > office when it wasn't working, printing outages tend to irritate people > a lot. > > > I'd set up the print queue again from scratch. Maybe. > > Neither rebooting nor recreating the print queue the same way would have > resolved this particular issue. Trying to recreate it in a different > way (using the IP instead of mDNS) may have helped. > > I understand cups probably couldn't have worked out exactly what went > wrong in this case. Nonetheless, there are a few things the printing > troubleshooter could do (wishlist items): > > - check for syslog messages from any source (e.g. hplip, avahi) that > have a severity >= LOG_WARN between the time the job was sent and the > time the printer went offline and make the user aware of that early on > > - check the cups log to see the last time a job was successful for that > queue, check the apt/dpkg logs to see if there has been any upgrading > without a reboot > > - ask the user if they added or changed any firewalls or IP settings > recently, maybe run some mDNS test We do have a printing wiki with a quite extensive troubleshooting section. There is nothing on firewalls but I can add that easily. Coincidentally, I was considering devoting part of a page to avahi and avahi-browse in the next week or two, which is why any detail you could provide would be useful. How would that suit, Odyx? Cheers. Brian.
Bug#840327: stopped working, no helpful feedback
On 10/10/16 21:22, Brian Potkin wrote: > On Mon 10 Oct 2016 at 18:15:15 +0200, Daniel Pocock wrote: > >> Package: cups >> Version: 1.7.5-11+deb8u1 >> >> Printing had been working fine for a long time but about 20 minutes ago >> I tried to print something and an error popup appeared in GNOME asking >> if I wanted to diagnose the printer. My document appeared paused in the >> queue. > > Printing "working fine" for a long time must indicate something to you. > Then it stops working. How is this a bug rather than a matter for > debian-user? Computer systems don't generally go into meltdown because > they feel unappreciated. > The bug isn't because it stopped working (I got it working again anyway) I raised a bug because I was hoping we could improve the user experience for people who don't know how to dig around in the log files. Maybe it should be a wishlist bug. >> I looked at /var/log/cups/*log and found nothing about the error > > You had debug logging enabled? > >> I went to the control panel and also the CUPS web interface on port 631 >> and tried re-enabling the printer and each time I did that it failed again. >> >> I looked at /var/log/daemon.log and observed: >> >> hpcups[16590]: prnt/hpcups/HPCupsFilter.cpp 707: First raster data plane.. >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 1... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 2... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 3... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 4... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 5... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 6... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 7... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 8... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 9... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 10... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 11... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 12... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 13... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 14... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 15... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 16... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 17... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 18... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 19... >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 20... >> hp[16592]: io/hpmud/jd.c 816: error timeout mdns lookup ABC123DEF.local >> hp[16592]: io/hpmud/jd.c 93: unable to read device-id >> hp[16592]: prnt/backend/hp.c 808: ERROR: open device failed stat=12: >> hp:/net/HP_LaserJet_3055?zc=ABC123DEF > > This is a symptom indicating you have done something to the system. It > never happened before; why should it happen now? Things don't generally > occur out of the blue. > After looking more closely, I believe the root cause was a recent firewall change that was interfering with mDNS. Tweaking the firewall makes it work again. This hadn't been obvious because some other devices had been able to send stuff to the printer and the printer and the printer's web admin pages were accessible. >> I killed the cups process and modified /etc/cups/printers.conf to change >> the URI from: >> >> DeviceURI hp:/net/HP_LaserJet_3055?zc=ABC123DEF >> >> to something like: >> >> DeviceURI hp:/net/HP_LaserJet_3055?ip=192.168.1.234 >> >> >> and started cups again and now printing works again. >> >> What is really wrong here? > > Who knows? Having to do this is a sign of a non-optimal setup in some > way. You are the one in charge of the system. You've not touched > anything in the last year (or twenty minutes)? > >> Why did the popup not tell me the root cause of the problem? Why did I >> have to go hunting around in the log files like this? How many >> non-developers would be comfortable troubleshooting a problem like that >> without more details? > > System administrators should always feel comfortable about trouble > shooting. Admit it; you really love log files. :) > If I love log files, why would I have packaged LogAnalyzer[1] ? As I mentioned earlier, I opened the bug report to see if there is anything we can do to make this easier for people who are not sysadmins or DDs. I had a colleague who saw somebody throw a printer across an office when it wasn't working, printing outages tend to irritate people a lot. > I'd set up the print queue again from scratch. Maybe. > Neither rebooting nor recreating the print queue the same way would have resolved this particular issue. Trying to recreate it in a different way (using the IP instead of mDNS) may have helped. I understand cups
Bug#840327: stopped working, no helpful feedback
On 11/10/16 10:16, Brian Potkin wrote: > On Mon 10 Oct 2016 at 18:41:46 +0200, Daniel Pocock wrote: > >> On 10/10/16 18:24, Didier 'OdyX' Raboud wrote: >>> Control: tags -1 +moreinfo >>> >>> Hi Daniel, >>> >>> Le lundi, 10 octobre 2016, 18.15:15 h CEST Daniel Pocock a écrit : hpcups[16590]: prnt/hpcups/HPCupsFilter.cpp 707: First raster data plane.. hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 1... (…) hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 20... hp[16592]: io/hpmud/jd.c 816: error timeout mdns lookup ABC123DEF.local >>> >>> It looks like you have experienced some ZeroConf hiccup, wich your mdns >>> failing to resolve 'ABC123DEF.local' for some time, and letting the address >>> resolution timeout. >>> >> >> Yes, the same log entries appeared each time I re-enabled the printer. >> It tried for 20 seconds and then gave up and disabled the printer again. >> >>> I don't really see how a complex backend/networking(/WiFi >>> ?)/autoconfiguration >>> bug could be better handled. If it's misterious for you and me, I don't see >>> how CUPS is supposed to handle and interpret HPLIP-specific stderror >>> daemon.log >>> output. >>> >>> This really looks like a one-time network hiccup; it could also be a >>> problem >>> in HPLIP, or in avahi. >>> >> >> >> I'm guessing that the problem will probably go away after a reboot, but >> I don't like telling users that they need to reboot Debian to fix >> things. I did try rebooting the printer though and that didn't help. >> >> I'm not familiar with HPLIP or avahi, would you know anybody who could >> comment on this or suggest further details I should obtain from the >> system before it is rebooted? > > Please do > > avahi-browse -art > filename > > and post filename. avahi-browse is in the avahi-utils package. > > Also post the outputs of > > /usr/sbin/lpinfo -v > /usr/lib/cups/backend/snmp > ping -c3 ABC123DEF.local > I found out that the root cause appeared to be a firewall change that was specifically blocking the mDNS stuff while other things still worked, I commented on it in this reply on debian-printing: https://lists.debian.org/debian-printing/2016/10/msg00079.html Is there anything the avahi tools can do in scenarios like this to provide more information through the printing diagnostic wizard? Regards, Daniel
Bug#840327: stopped working, no helpful feedback
On Mon 10 Oct 2016 at 18:41:46 +0200, Daniel Pocock wrote: > On 10/10/16 18:24, Didier 'OdyX' Raboud wrote: > > Control: tags -1 +moreinfo > > > > Hi Daniel, > > > > Le lundi, 10 octobre 2016, 18.15:15 h CEST Daniel Pocock a écrit : > >> hpcups[16590]: prnt/hpcups/HPCupsFilter.cpp 707: First raster data plane.. > >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 1... > >> (…) > >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 20... > >> hp[16592]: io/hpmud/jd.c 816: error timeout mdns lookup ABC123DEF.local > > > > It looks like you have experienced some ZeroConf hiccup, wich your mdns > > failing to resolve 'ABC123DEF.local' for some time, and letting the address > > resolution timeout. > > > > Yes, the same log entries appeared each time I re-enabled the printer. > It tried for 20 seconds and then gave up and disabled the printer again. > > > I don't really see how a complex backend/networking(/WiFi > > ?)/autoconfiguration > > bug could be better handled. If it's misterious for you and me, I don't see > > how CUPS is supposed to handle and interpret HPLIP-specific stderror > > daemon.log > > output. > > > > This really looks like a one-time network hiccup; it could also be a > > problem > > in HPLIP, or in avahi. > > > > > I'm guessing that the problem will probably go away after a reboot, but > I don't like telling users that they need to reboot Debian to fix > things. I did try rebooting the printer though and that didn't help. > > I'm not familiar with HPLIP or avahi, would you know anybody who could > comment on this or suggest further details I should obtain from the > system before it is rebooted? Please do avahi-browse -art > filename and post filename. avahi-browse is in the avahi-utils package. Also post the outputs of /usr/sbin/lpinfo -v /usr/lib/cups/backend/snmp ping -c3 ABC123DEF.local Cheers, Brian.
Bug#840327: stopped working, no helpful feedback
On Mon 10 Oct 2016 at 18:15:15 +0200, Daniel Pocock wrote: > Package: cups > Version: 1.7.5-11+deb8u1 > > Printing had been working fine for a long time but about 20 minutes ago > I tried to print something and an error popup appeared in GNOME asking > if I wanted to diagnose the printer. My document appeared paused in the > queue. Printing "working fine" for a long time must indicate something to you. Then it stops working. How is this a bug rather than a matter for debian-user? Computer systems don't generally go into meltdown because they feel unappreciated. > I looked at /var/log/cups/*log and found nothing about the error You had debug logging enabled? > I went to the control panel and also the CUPS web interface on port 631 > and tried re-enabling the printer and each time I did that it failed again. > > I looked at /var/log/daemon.log and observed: > > hpcups[16590]: prnt/hpcups/HPCupsFilter.cpp 707: First raster data plane.. > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 1... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 2... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 3... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 4... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 5... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 6... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 7... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 8... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 9... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 10... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 11... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 12... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 13... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 14... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 15... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 16... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 17... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 18... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 19... > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 20... > hp[16592]: io/hpmud/jd.c 816: error timeout mdns lookup ABC123DEF.local > hp[16592]: io/hpmud/jd.c 93: unable to read device-id > hp[16592]: prnt/backend/hp.c 808: ERROR: open device failed stat=12: > hp:/net/HP_LaserJet_3055?zc=ABC123DEF This is a symptom indicating you have done something to the system. It never happened before; why should it happen now? Things don't generally occur out of the blue. > I killed the cups process and modified /etc/cups/printers.conf to change > the URI from: > > DeviceURI hp:/net/HP_LaserJet_3055?zc=ABC123DEF > > to something like: > > DeviceURI hp:/net/HP_LaserJet_3055?ip=192.168.1.234 > > > and started cups again and now printing works again. > > What is really wrong here? Who knows? Having to do this is a sign of a non-optimal setup in some way. You are the one in charge of the system. You've not touched anything in the last year (or twenty minutes)? > Why did the popup not tell me the root cause of the problem? Why did I > have to go hunting around in the log files like this? How many > non-developers would be comfortable troubleshooting a problem like that > without more details? System administrators should always feel comfortable about trouble shooting. Admit it; you really love log files. :) I'd set up the print queue again from scratch. Maybe. Regards, Brian.
Bug#840327: stopped working, no helpful feedback
On 10/10/16 18:24, Didier 'OdyX' Raboud wrote: > Control: tags -1 +moreinfo > > Hi Daniel, > > Le lundi, 10 octobre 2016, 18.15:15 h CEST Daniel Pocock a écrit : >> hpcups[16590]: prnt/hpcups/HPCupsFilter.cpp 707: First raster data plane.. >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 1... >> (…) >> hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 20... >> hp[16592]: io/hpmud/jd.c 816: error timeout mdns lookup ABC123DEF.local > > It looks like you have experienced some ZeroConf hiccup, wich your mdns > failing to resolve 'ABC123DEF.local' for some time, and letting the address > resolution timeout. > Yes, the same log entries appeared each time I re-enabled the printer. It tried for 20 seconds and then gave up and disabled the printer again. > I don't really see how a complex backend/networking(/WiFi > ?)/autoconfiguration > bug could be better handled. If it's misterious for you and me, I don't see > how CUPS is supposed to handle and interpret HPLIP-specific stderror > daemon.log > output. > > This really looks like a one-time network hiccup; it could also be a problem > in HPLIP, or in avahi. > I'm guessing that the problem will probably go away after a reboot, but I don't like telling users that they need to reboot Debian to fix things. I did try rebooting the printer though and that didn't help. I'm not familiar with HPLIP or avahi, would you know anybody who could comment on this or suggest further details I should obtain from the system before it is rebooted? Regards, Daniel
Bug#840327: stopped working, no helpful feedback
Control: tags -1 +moreinfo Hi Daniel, Le lundi, 10 octobre 2016, 18.15:15 h CEST Daniel Pocock a écrit : > hpcups[16590]: prnt/hpcups/HPCupsFilter.cpp 707: First raster data plane.. > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 1... > (…) > hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 20... > hp[16592]: io/hpmud/jd.c 816: error timeout mdns lookup ABC123DEF.local It looks like you have experienced some ZeroConf hiccup, wich your mdns failing to resolve 'ABC123DEF.local' for some time, and letting the address resolution timeout. I don't really see how a complex backend/networking(/WiFi ?)/autoconfiguration bug could be better handled. If it's misterious for you and me, I don't see how CUPS is supposed to handle and interpret HPLIP-specific stderror daemon.log output. This really looks like a one-time network hiccup; it could also be a problem in HPLIP, or in avahi. -- Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#840327: stopped working, no helpful feedback
Package: cups Version: 1.7.5-11+deb8u1 Printing had been working fine for a long time but about 20 minutes ago I tried to print something and an error popup appeared in GNOME asking if I wanted to diagnose the printer. My document appeared paused in the queue. I looked at /var/log/cups/*log and found nothing about the error I went to the control panel and also the CUPS web interface on port 631 and tried re-enabling the printer and each time I did that it failed again. I looked at /var/log/daemon.log and observed: hpcups[16590]: prnt/hpcups/HPCupsFilter.cpp 707: First raster data plane.. hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 1... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 2... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 3... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 4... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 5... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 6... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 7... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 8... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 9... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 10... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 11... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 12... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 13... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 14... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 15... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 16... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 17... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 18... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 19... hp[16592]: io/hpmud/jd.c 820: mdns lookup ABC123DEF.local retry 20... hp[16592]: io/hpmud/jd.c 816: error timeout mdns lookup ABC123DEF.local hp[16592]: io/hpmud/jd.c 93: unable to read device-id hp[16592]: prnt/backend/hp.c 808: ERROR: open device failed stat=12: hp:/net/HP_LaserJet_3055?zc=ABC123DEF I killed the cups process and modified /etc/cups/printers.conf to change the URI from: DeviceURI hp:/net/HP_LaserJet_3055?zc=ABC123DEF to something like: DeviceURI hp:/net/HP_LaserJet_3055?ip=192.168.1.234 and started cups again and now printing works again. What is really wrong here? Why did the popup not tell me the root cause of the problem? Why did I have to go hunting around in the log files like this? How many non-developers would be comfortable troubleshooting a problem like that without more details?
