[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.
