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

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.

Thanks in advance

Helmut

tags 846381 moreinfo
thanks



Thanks you for your report, Helmut.

What are the symptoms?  How do you know that the printing system does
not see the remote broadcasted printers on the clients?

cups-browsed browses the mdns broadcasts and makes the remote printers
available to applications.

Being able to reproduce behaviour is always a plus and, in some cases,
a necessity.

First things first. Are you still experiencing this behaviour on an
up-to-date unstable/testing system?

Control: tags -1 - moreinfo

Thanks for looking into this.

When printers are broadcasted, client cups systems create
/etc/cups/ppd/<something>.ppd for each remote printer. These files exist
after booting and then vanish. Another way to diagnose the presence of
the issue is running "lpstat -a". After boot, it lists all the printers,
but after a while, the output becomes "lpstat: No destinations added."
When I try to print something (e.g. using evince), I am presented with
an empty printer list. Then I restart avahi-daemon on the client system
and the files are back and "lpstat -a" gives a printer list again until
it forgets again.

Yes. I see this behaviour on stretch and sid.

Is there anything else I can check? Maybe trace something? Turn on some
debug logging somewhere? The issue is sufficiently annoying that I am
willing to put some time into it.

Helmut

cups-browsed creates the PPDs.

lpstat gets remote printer information from cups-browsed.

evince can get remote printer information from cups-browsed but, if the
latter is not running, it browses the Bonjour broadcasts of servers and
printers directly, just as avahi-browse does.

I am working with sid. Are you using AppArmor on Stretch?

Let's see whether cups-browsed has any connection with the issue. Stop
it running and bring up evince. Its print dialog should show the remote
printers it gets from mdns broadcasts. You relate the printers disappear
a few times a day, so we shouldn't have to wait too long to see whether
it happens in this situation. BTW, is there any discernable pattern to
the behaviour? Time of day, time interval etc?

Thanks for the offer. Have a good look at what journalctl says. Search
for clues with "avahi", "audit", SIGTERM (and anything else you can
think of).

Cheers,

Brian.

I cannot confirm the described behaviour.

I have never explicitly enabled AppArmor. The stretch system is pretty
close to a standard installation. I haven't fiddled with it much.

The sid system certainly isn't using AppArmor and could have a few
oddities: It was installed as potato and upgraded since.

As soon as I stop cups-browsed, all printers disappear. The ppd files
are deleted. lpstat does not know them anymore and they disappear from
the evince print dialog (or don't show up there if I restart evince).
When cups-browsed is started again, the printers in evince, the ppd
files and the lpstat output is back again pretty much immediately.

Concerning the timing, I looked hard before filing the bug report. Log
rotation was something obvious to correlate it to, but without luck. The
waiting time seems exponentially distributed to me. Sometimes I had it
multiple times within an hour other times a day went by without.

When I ran the whole thing under strace, it didn't happen within 12h.

I checked that much before the filing. I'm afraid we'll need to turn on
some more logging to get useful things here. Just what should I enable?
The manual page of avahi-daemon.conf is pretty scarce on debugging
options. cups-browsed logging is pretty much off by default and when you
enable it you only see the fact that printers get removed, not why.

You see, this issue is not easy to debug. I hope you can bear with me.

Helmut

The print dialog is empty when cups-browsed is stopped? Mystifying! GTK+
uses the avahi library to list printers and print queues advertised by
the DNS-SD protocol.

https://bugzilla.gnome.org/show_bug.cgi?id=688956

You have attained a goal others have striven for. :)

https://lists.debian.org/debian-user/2017/09/msg00980.html

Just ruling out AppArmor. It would have to be explicitly installed on
stretch....

...but not on unstable as it is a Recommends: of linux-image.

I hate it when events are random.

You appear to have exhausted all the options I would suggest.

My interest in this bug arises from its affecting cups-daemon and my
knowledge of avahi is not great. It seems avahi-daemon stops providing
cups-browsed with information and the printer list would disappear, of
course. I would have been interesting to find out if the same thing
happens with the GTK dialog.

Cheers,

Brian.

affects 846381 - cuos-daemon
thanks


On Tue 02 Jan 2018 at 17:51:06 +0000, Brian Potkin wrote:

[...]

I am using cups 2.4.2-1+b1 on unstable with a default avahi-daemon.conf
and do not observe what you describe in your first post. cups always
sees the printers with 'lpstat -l -e'.

Cheers,

Brian.

Dear Maintainer,

I think I am still running into the same issue, although
remote cups servers are not involved -- just local printing
on a WiFi printer. The symptom I see is the print queue being
stuck, and the printer showing in different interfaces (Plasma
settings "Printers" tab, as well as lpstat) the message

No destination host name supplied by cups-browsed for printer "(name)",
is cups-browsed running?

A better description of the problem I encountered is
https://github.com/OpenPrinting/cups-browsed/issues/23

and as I noted in a comment
https://github.com/OpenPrinting/cups-browsed/issues/23#issuecomment-3765203139

Restarting Avahi restored printing.