tags 846381 moreinfo thanks
Thanks you for your report, Helmut. On Wed 30 Nov 2016 at 20:57:01 +0100, Helmut Grohne wrote: > Package: avahi-daemon > Version: 0.6.31-5 > Control: affects -1 cups-daemon > > Since Debian jessie, cups uses avahi to broadcast its printers to the > local network. I have a jessie cups with a few printers and publish them > via avahi. Now I am seeing a little weird behaviour on client systems: > After booting their cups daemons know about the broadcasted printers, > but after some time (usually a few times a day) they forget. I have no What are the symptoms? How do you know that the printing system does not see the remote broadcasted printers on the clients? > clue what causes the client cups to forget about all network printers, > but after issuing "service avahi-daemon restart" on the client machine, > all the printers are back. Restarting something else (such as cups) > doesn't get me the printers back instead. This lets me conclude that > avahi-daemon somehow is the cause. I am observing this with both jessie > and unstable client systems, so stretch is affected. The cups-browsed browses the mdns broadcasts and makes the remote printers available to applications. > avahi-daemon.conf is pretty much the default with the exception of > setting disable-publishing=yes on all client systems. I have no idea how > to reliably trigger this bug (beyond waiting a day). Before and after > restarting avahi-daemon, the output of "avahi-browse -at" looks no > different (i.e. printers always show up there). Being able to reproduce behaviour is always a plus and, in some cases, a necessity. > I understand that this bug description is quite vague. Still, it is > fairly annoying and as it happens on multiple systems some of which are > pretty close to defaults, I believe still believe it to be a bug. I > already spent considerable time trying to diagnose it and intend to do > further diagnosis if someone can provide hints as to what to check. It > might even be a cups bug. Please reassign as appropriate. First things first. Are you still experiencing this behaviour on an up-to-date unstable/testing system?
