Re: How long until a deleted printer actually vanishes?
On Sat, Jan 26, 2019 at 07:02:21PM +0000, Brian Potkin wrote:
> On Sat 26 Jan 2019 at 15:51:51 +0100, Marc Haber wrote:
> > On Fri, Jan 25, 2019 at 06:42:25PM +0000, Brian Potkin wrote:
> > > On Fri 25 Jan 2019 at 16:27:36 +0100, Marc Haber wrote:
> > > > in my overengineered home network, I have
> > > >
> > > > - a VLAN with my Laser Printer and an Inkjet.
> > > > - another VLAN with my CUPS server, parada, running Debian stable
> > > > - another VLAN with my desktop workstation, fan, running Debian
> > > > unstable and KDE.
> > > > - a router/firewall, barrida, running a packet filter and avahi-daemon
> > > > in reflector configuration.
> > >
> > > I have no knowledge or experience of VLANs or reflectors but I will
> > > give my interpretation of what the setup does. Please correct it if
> > > necessary.
> >
> > This is very helpful anyway. I am an experienced networker, so we can
> > probably together make sense from that. I am especially interested in
> > learning about what avahi does and how to debug it.
>
> My main debugging tool is avahi-browse,
In avahi-browse, I fail to make the connection between the service type
such as _http._tcp and the output. For example:
[11/5292]mh@drop:~ $ sudo avahi-browse --all --terminate | grep parada
+ lanw0 IPv6 Lexmark C534 @ parada Internet Printer local
+ lanw0 IPv6 Canon MX420 series @ parada Internet Printer local
+ lanw0 IPv6 AirPrint c534-ka51 @ parada Internet Printer local
+ lanw0 IPv4 AirPrint c534-ka51 @ parada Internet Printer local
+ lanw0 IPv4 Lexmark C534 @ parada Internet Printer local
+ lanw0 IPv4 Canon MX420 series @ parada Internet Printer local
+ lanw0 IPv6 Lexmark C534 @ parada Secure Internet Printer local
+ lanw0 IPv6 Canon MX420 series @ parada Secure Internet Printer local
+ lanw0 IPv4 Lexmark C534 @ parada Secure Internet Printer local
+ lanw0 IPv4 Canon MX420 series @ parada Secure Internet Printer local
+ lanw0 IPv6 Canon MX420 series @ parada UNIX Printer local
+ lanw0 IPv6 Lexmark C534 @ parada UNIX Printer local
+ lanw0 IPv4 Canon MX420 series @ parada UNIX Printer local
+ lanw0 IPv4 Lexmark C534 @ parada UNIX Printer local
+ lanw0 IPv6 CUPS @ parada Web Site local
+ lanw0 IPv4 CUPS @ parada Web Site local
[12/5293]mh@drop:~ $
I would assume that each of this lines has a pseudo "host name" under the .local domain?
Also, avahi-browse --all --terminate --resolve gives me a truckload of messages like
Failed to resolve service 'Lexmark C534 @ parada' of type '_ipp._tcp' in domain 'local': Timeout reached
that I cannot make sense from.
When the Lexmark printer is on, avahi-browse on parada also sees it:
[15/3715]mh@parada:~ $ sudo avahi-browse --all --terminate | grep -iE '(534|lexmark)' | grep -v parada
+ eth0 IPv4 c534-ka51 FTP File Transfer local
+ eth0 IPv4 c534-ka51 UNIX Printer local
+ eth0 IPv4 c534-ka51 Internet Printer local
+ eth0 IPv4 c534-ka51 Web Site local
[16/3716]mh@parada:~ $
And I _think_ that the printer prints PDFs uploaded via ftp just fine,
although CUPS seems to access it via _printer._tcp:
[21/3721]mh@parada:~ $ sudo lpinfo -v | grep c534
network dnssd://c534-ka51._printer._tcp.local/
[22/3722]mh@parada:~ $
> but on occasion I have used a
> .service file in /etc/avahi/services/. See message #7 at
>
> https://bugs.launchpad.net/hplip/+bug/1797501
So you basically created a test service in your avahi that _should_ look
identical to the one you were expecting?
> > AirPrint_c534_ka51_parada (Paused, Rejecting Jobs, Not Shared)
> > Description: AirPrint_c534_ka51_parada
> > Location:
> > Driver: Local Raw Printer (grayscale, 2-sided printing)
> > Connection: file:///dev/null
> > Defaults: job-sheets=none, none media=unknown
> >
> > After cleaning up, fan now has zero queues visible in fan:631/printers,
>
> That's ok. You have no local queues set up by you or cups-browsed.
That was my intention for debugging purposes.
> > and parada:631/printers only shows the Inkjet:
>
> Am I missing something? Where is the Lexmark?
That one was not present at the time of this try. The
"AirPrint_c534_ka51_parada" definition was a phantom that vanished with
restarting CUPS on parada. I cannot reproduce this and thus would not
investigate this any further unless this behavior keeps showing up
> > mx420-ka51 (Idle, Accepting Jobs, Shared)
> > Description: Canon MX420 series
> > Location: KA51 KE
> > Driver: Canon PIXMA-MX426 Foomatic/gutenprint-ijs-simplified.5.2 (color)
> > Connection: dnssd://MX420-KA51._printer._tcp.local/
> > Defaults: job-sheets=none, none media=iso_a4_210x297mm
> > sides=one-sided
> >
> > evince on fan shows
> > c534-ka51 Lexmark C534-KA51 on parada
> > mx420-ka51 KA51 KE
>
> And both can be printed to?
No, the "c534-ka51 Lexmark C534-KA51 on parada" didn't work, and I
don't remember the message I received when trying to print. I guess that
there was no error message and the print job just vanished in tht
darkness.
> > > > Which daemons (cups? cups-browsed? avahi?) on which hosts do I restart
> > > > to have the old printer entry vanish? Or, alternatively, how long do I
> > > > have to wait until those entries time out eventually?
> > >
> > > Stop CUPS on parada; the Inkjet entry(ies) should disappear from Evince.
> > > What happens to c534-ka51 Lexmark C534-KA51 on parada? Restarting CUPS
> > > should see Inkjet reappear almost instantaneously in Evince.
> >
> > Stopping cups on parada made both entries vanish, starting cups on
> > parada again made the inkjet reappear.
>
> So parada was responsible for the Lexmark queue. It's gone now, so we
> will not worry about it.
Right.
>
> > > Now stop CUPS on fan (this also stops cups-browsed). What happens in
> > > Evince?
> >
> > cups-browsed on fan was already gone when I did those experiments, so
> > stopping and starting CUPS on fan didn't have any effect. Do I see
> > correctly that CUPS on fan is not needed to access the printers served
> > by parada from applications running on fan?
>
> Not quite. Correct for the GTK print dialog but not for the LibreOffice
> and Qt ones. On buster, the later two enumerate remote queues and IPP
> printers using CUPS' temporary queue mechanism (see the wiki Glossary
> and Index).
Without cups-browsed, lpstat gives me the following:
[5/3708]mh@parada:~ $ lpstat -a
c534-ka51 accepting requests since Sa 26 Jan 2019 15:36:04 CET
mx420-ka51 accepting requests since So 23 Sep 2018 17:06:38 CEST
[6/3709]mh@parada:~ $ lpstat -l -e
lpstat: Error - unknown option "e".
[7/3710]mh@parada:~ $
[6/4999]mh@fan:~ $ lpstat -a
lpstat: No destinations added.
1 [7/5000]mh@fan:~ $ lpstat -l -e
AirPrint_c534_ka51_parada network none ipp://AirPrint%20c534-ka51%20%40%20parada._ipp._tcp.local/cups
Canon_MX420_series_parada network none ipps://Canon%20MX420%20series%20%40%20parada._ipps._tcp.local/cups
Lexmark_C534_parada network none ipps://Lexmark%20C534%20%40%20parada._ipps._tcp.local/cups
[8/5001]mh@fan:~ $
So, CUPS 2.2.10 on fan will create those temporary queues automatically
even without cups-browsed, right?
> > > > Another question, will my Lexmark C534 (it can do Postscript, prints PDF
> > > > uploaded via ftp and alot more, but does not do AirPrint by itself) be
> > > > eligible for driverless printing?
> > >
> > > No. It doesn't use DNS-SD broadcasting.
> >
> > Ok. So I recreated a queue ("Lexmark C534") on parada, and I can print
> > from fan now. Thanks. That was painless.
> >
> > c534-ka51 (Idle, Accepting Jobs, Shared)
> > Description: Lexmark C534
> > Location: KA51 KE
> > Driver: Lexmark C534dtn Foomatic/Postscript (recommended) (color, 2-sided printing)
> > Connection: dnssd://c534-ka51._pdl-datastream._tcp.local/
> > Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided
> >
> > Now my wife's iPad. The iPad sees the Lexmark C534 queue, and printing
> > there works. Glacially slow, but it works, and the iPad gives an
> > unspecific error message ("Error while printing" in German), before the
> > print job prints OK. She doesn't see the mx420-ka51 queue.
> >
> > There is clearly something going wrong here. How can I influence this?
>
> You would have to look at an error_log (how to get one is on the wiki)
> to track if the printing system is responsible for the slowness.
Will the hints given in
https://wiki.debian.org/DissectingandDebuggingtheCUPSPrintingSystem also
apply to buster? The wiki page only mentions jessie and stretch.
Oh, btw, the work you guys have done on the Wiki starting
https://wiki.debian.org/Printing is just great. I love it.
Don't get me started about the CUPS error_log though. Uncounted the
times where stracing the CUPS daemon immediately showed a clear error
message from auxillary proceses such as "ghostscript: unable to write to
/var/tmp, permission denied" but that never showed up in the CUPS
error_log even in the higest debug setting. A horrible mess.
> I am unfamiliar with iDevices but I wouldn't have thought that mattered,
> (maybe). fan can see the mx420-ka51 queue (on parada,we assume), so why
> not the iPad? I'll have a think. You could try setting the queues on fan
> to shared.
The iPad now sees all three queues, and printing on the Lexmark queue
works in reasonable time (now that I have given my wife a simple PDF to
print). The one that was so slow was in color, with color gradients, so
it might have been legitimate to take ages to render. I also have a bank
that keeps sending statement PDFs that literally take five minutes to
render, maybe their (monochrome) logo is sent as a 30.000 dpi bitmap or
so.
> > KDE applications such as okular see historical printer queues that have
> > been deleted from CUPS long ago, "AirPrint_c534_ka51_parada",
> > "Canon_MX420_series_parada" and "Lexmark_C534_parada". none of which
> > seem to work. For example, the Lexmark_C534_parada printer entries does
> > not allow me to set values for Duplex (grey) or nup (not present in the
> > dialogs) printing.
>
> Do you see the same three queues with 'lpstat -l -e'?
Yes, I do, see above. But they don't seem to work, and not all features
of the printer such as duplex printing and not all features of CUPS such
as n-up printing seem to be handed through.
Where does the AirPrint queue come from? It seems to be gratuitous, both
Linux and the iDevices print to the regular "Lexmark_C534_parada" queue
just fine.
> > When I tell okular to actually print, it says on the console
> > "/usr/bin/lpr: No such file or directory", but that file is present,
> > from cups-bsd, and invoking it manually from the same shell says "lpr:
> > Error - No default destination." stracing okular for hints why this
> > fails makes me end up without available printers at all.
>
> You have confirmed Bug #911702. Do you fancy having a go at #911844?
Ouch. Those two, and the upstream bug, and the lack of any
maintainer/upstream reaction looks very very frustrating.
> Installing cups-browsed on fan is necessary to avoid both bugs.
And okular will immediately and happily print once cups-browsed is
installed on fan despite it having CUPS 2.2.10?
After installing cups-browsed on fan I now have:
AirPrint_c534_ka51_parada accepting requests since So 27 Jan 2019 18:50:14 CET
Canon_MX420_series_parada accepting requests since So 27 Jan 2019 18:50:14 CET
Lexmark_C534_parada accepting requests since So 27 Jan 2019 18:50:13 CET
[18/5010]mh@fan:~ $ lpstat -l -e
AirPrint_c534_ka51_parada network none ipp://AirPrint%20c534-ka51%20%40%20parada._ipp._tcp.local/cups
Canon_MX420_series_parada network none ipps://Canon%20MX420%20series%20%40%20parada._ipps._tcp.local/cups
Lexmark_C534_parada network none ipps://Lexmark%20C534%20%40%20parada._ipps._tcp.local/cups
[19/5011]mh@fan:~ $
And, indeed, okular prints just fine to the Lexmark_C534_parada queue, I
can now see and activate all features of the printer, same goes for
LibreOffice. I cannot think of any other use case that I need urgently.
I think that all of my real problems have been solved with your help,
with the only real changes that were done were removing cups-browsed
from parada, deleting all queues on fan and recreating the Lexmark queue
on parada.
Btw, I have been wondering for years whether there is a mechanism
cleaning up temporary spool files from past print jobs on the CUPS
server. /var/*/cups on parada is surprisingly clean in these days, so
there must be some (rather new?) mechanism.
And, also btw, when I print sensitive stuff like passwords etc, would it
be sufficient to temporarily mount a tmpfs over /var/spool/cups and
restart the daemon to avoid this sensitive data staying on disk? Since
the system must always be ready to lose /var/spool, maybe having a LUKS
device mounted with a random key on /var/spool/cups would be a good idea
for parada? Probably also /var/tmp, right (/tmp is a tmpfs anyway).
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Reply to: