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.
Reply to: