Re: How long until a deleted printer actually vanishes?
On Sun 27 Jan 2019 at 19:08:22 +0100, Marc Haber wrote:
> On Sat, Jan 26, 2019 at 07:02:21PM +0000, Brian Potkin wrote:
> >
> > 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:~ $
https://developer.apple.com/bonjour/printing-specification/bonjourprinting-1.2.1.pdf
could help.
> 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?
Yes.
> > That's ok. You have no local queues set up by you or cups-browsed.
>
> That was my intention for debugging purposes.
>
> > 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
>
> > 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.
>
> > So parada was responsible for the Lexmark queue. It's gone now, so we
> > will not worry about it.
>
> Right.
>
> > 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
'lpstat -a' only shows local queues. You have set these two up.
> [6/3709]mh@parada:~ $ lpstat -l -e
> lpstat: Error - unknown option "e".
> [7/3710]mh@parada:~ $
'-e' is a new option to lpstat. buster only.
> [6/4999]mh@fan:~ $ lpstat -a
> lpstat: No destinations added.
Destinations are added when a dialog entry (not GTK) is printed to.
> 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?
Yes. But note that a queue is only created (a PPD appears and stays in
/etc/cups/ppd for a minute) when the dialog entry is printed to. Queues
created by cups-browsed are permanent queues.
> > 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.
Yes. The page will be reviewed and readjusted in the near future. Its
general thrust and most of the detail is unchanged by what buster brings
to the table.
> Oh, btw, the work you guys have done on the Wiki starting
> https://wiki.debian.org/Printing is just great. I love it.
Thank you.
> 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
That's a win, isn't it? Very pleasing because I think it was one of your
main objectives.
> 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.
In many ways the printing system is at the mercy of PDF it has to deal
with. This crops up from time to time; I generally try to avoid dealing
with a user's "bad" PDF issues.
> > > 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.
A little. But, in time, someone in a position to take action will
notice and act. For the time being, cups-browsed, which will be on
most Linux systems, saves the day. It's best to be pragmatic.
> > 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?
I told you you would be glad to have cups-browsed around. Essentially,
cups-browsed takes over the temporary queue name allotted by CUPS to
create permanent, local queues it can manipulate. For example, CUPS
does not allow filtering of print queues to display, but cups-browsed
does.
> 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:~ $
That's as it should be. In practice (barring bugs) a user would see no
difference, with or without cups-browsed, and printing should "just
work". As I have mentioned above, cups-browsed comes into its own for
things CUPS does not handle. Another example: it can deal with raw
queues being shared by parada.
> 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.
Splendid.
> 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.
I think that is the PreserveJobFiles option. It can go in cups.conf.
The default is 24 hours.
> 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).
Sorry, I cannot help with that.
Regards,
Brian.
Reply to: