Bug 1954469 - driverless sometimes ends with 'ERROR: ippfind (PID N) stopped with status 1!' when a printer is on LAN
Summary: driverless sometimes ends with 'ERROR: ippfind (PID N) stopped with status 1!...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: cups-filters
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-28 08:25 UTC by Zdenek Dohnal
Modified: 2021-08-10 12:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Zdenek Dohnal 2021-04-28 08:25:08 UTC
driverless binary, which is used for looking for driverless device uri or generating driverless PPDs, can fail sometimes even if the printer is available and seen via avahi-browse:

$ driverless list

The correct status:
DEBUG: Started ippfind (PID 39831)
"driverless:ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/" en "HP" "HP LaserJet M1536dnf MFP, driverless, cups-filters 1.28.7" "MFG:HP;MDL:LaserJet M1536dnf MFP;CMD:PDF,PS,PCL,AppleRaster,URF;"
DEBUG: ippfind (PID 39831) exited with no errors.

The error which happens sometimes:
DEBUG: Started ippfind (PID 39806)
ERROR: ippfind (PID 39806) stopped with status 1!

I enabled debug logging on Avahi and I see that there is no resolver methods spawned when the error happens, but I haven't been able to isolate the issue in ippfind, which is executed from driverless.

I will ask the cups-filters upstream for the exact ippfind command they use in driverless (I wasn't able to set it up according driverless code).

Workaround:
- give it an other try

Comment 1 Zdenek Dohnal 2021-04-28 08:42:11 UTC
The bug influences every device listing - so f.e. gnome-control-center, lpinfo -v, system-config-printer and cups web ui are affected.

However, this bug isn't blocker, because driverless/IPP everywhere enabled printers can print via temporary queues or the device uri can be created manually by user. Common uris are:

ipp://IP:631/ipp/print
ipp://hostname:631/ipp/print

Comment 2 Solomon Peachy 2021-05-25 11:34:21 UTC
I'm seeing a similar, yet slightly different issue on a fully updated F34 box:

$  driverless list
DEBUG: Started ippfind (PID 152478)
ERROR: ippfind (PID 152478) stopped with status 2!

$ rpm -qf /usr/bin/driverless
cups-filters-1.28.8-1.fc34.x86_64

re-running 'driverless' returns the same error every time.

(FWIW 'ippfind' shows 27 entries..)

This is the cmdline driverless seems to invoke:

ippfind -T 0 _ipps._tcp _ipp._tcp ! --txt printer-type --and \( --txt-pdl image/pwg-raster --or --txt-pdl application/PCLm --txt-pdl image/urf --or --txt-pdl application/pdf \) -x echo -en "{service_scheme}\t{service_name}\t..." \;

Dropping the '!' seems to make things work for me.  Not sure why it's there.

Comment 3 Zdenek Dohnal 2021-05-26 07:41:04 UTC
Hi Solomon,

I have F33 and I installed the newest cups-filters from updates-testing (1.28.8-1), and I cannot get the same error. I'll upgrade my second laptop (where I want to have always the latest Fedora for testing) and see if I can reproduce.

Anyway, the error code from ippfind is for IPPFIND_EXIT_BONJOUR - browsing or resolving error - it is hit when ippfind:

- cannot create avahi poll,
- cannot create avahi client on that poll,
- cannot create avahi browser on the client,
- when connection to Avahi failed and we've been told to stop iterating over our Avahi poll
- cannot create resolver on avahi client, which does resolving of .local addresses

However regarding 'ippfind' command - my understanding is that driverless utility wants to show uris only for real devices, not for remote cups queues which are advertised by cups server in the LAN - mdns records which are from cupsd on LAN have this 'printer-type' field in txt record, so that's why 'ippfind' in 'driverless' uses '! --txt printer-type'.
AFAIK 'driverless' was created to get IPP-Everywhere URI and PPD based on IPP communication via current printer driver architecture, so users would slowly move to driverless tech and, especially since GUI toolkits didn't support temp queues for long time, to make driverless work for them (although via permanent queues).

So if your setup is in a similar way (having a server which shares the queues, all devices are in different network than your PC - meaning they aren't shown in avahi-browse, driverless shows nothing and ippfind shows all remote queues), IMO driverless returning nothing is expected.

If that's the case, what I think as a bug is that error status (which can be a bug or result of other configuration), and IMO it would be nice to have 'driverless' configurable for showing uris/generating PPDs for remote queues shared via mDNS.

Plus, since GTK can support temp queues in F33 and we don't need to install a permanent queue or run cups-browsed for driverless device to make it work in GTK, I'm considering removal of 'driverless' from /usr/lib/cups/backend and /usr/lib/cups/driver, so it will not be run during installation.

=======================================================================================

To sum it up:

1) your issue doesn't look like a bug (if you have the configuration as I described above) or a different bug - I would be grateful if you could confirm what is your configuration. I can file a different bug for that.

2a) if your setup is as described above, then it is a bug to return 2 as a status code. The correct one should be '1'.

2b) if you have a different setup, I need to investigate further - maybe avahi, nss-mdns and resolved didn't play along

3) there is a possible feature for 'driverless' to support option for remote cups queues, but since GUIs can support temp queues nowadays in some way, IMO usage of 'driverless' is reduced to cases when something doesn't work and you need to have PPD based on IPP communication and create a permanent queue for it, so I don't see that as a critical feature to implement.

Comment 4 Solomon Peachy 2021-06-05 02:09:26 UTC
For whatever reason, I'm now unable to recreate the 'status 2' response.  

Here is a rundown of my configuration:

 * No native IPP printers
 * All advertised printers are queues exported from CUPS (27 in all, 26 unique printers)
   * One queue is native postscript, the rest go through gutenprint
 * Server and Client PC are both on the same local network, connected via ethernet.
 * Server and Client are both fully updated Fedora 34 systems (cups-2.3.3op2-7, cups-filters-1.28.8-1, avahi-0.8-9)
 * 'driverless list' returns "status 1"
 * ippfind returns all 27 "printers" with ipp://.... URIs.
 * avahi-browse returns all printers, exported with _ipp._tcp, _ipps._tcp, and _printer._tcp over IPv4
   * all of the above are the same for both server and PC

Except for the number of printers on a single system, I don't think it's anything unusual.

Please let me know if there's any more information you need.

Comment 5 Zdenek Dohnal 2021-06-07 05:24:27 UTC
(In reply to Solomon Peachy from comment #4)
> For whatever reason, I'm now unable to recreate the 'status 2' response.

Ok, do let me know if it shows up again by a new bug.

Thank you in advance!

> 
> Here is a rundown of my configuration:
> 
>  * No native IPP printers
>  * All advertised printers are queues exported from CUPS (27 in all, 26
> unique printers)
>    * One queue is native postscript, the rest go through gutenprint
>  * Server and Client PC are both on the same local network, connected via
> ethernet.
>  * Server and Client are both fully updated Fedora 34 systems
> (cups-2.3.3op2-7, cups-filters-1.28.8-1, avahi-0.8-9)
>  * 'driverless list' returns "status 1"
>  * ippfind returns all 27 "printers" with ipp://.... URIs.
>  * avahi-browse returns all printers, exported with _ipp._tcp, _ipps._tcp,
> and _printer._tcp over IPv4
>    * all of the above are the same for both server and PC
> 
> Except for the number of printers on a single system, I don't think it's
> anything unusual.

Ok, so AFAIK driverless behaves correctly in your setup. driverless chose to show only actual printers, not print queues shared by CUPS. But let's check up with Till on printing-architecture.

My problem is that I have a real printer on my LAN, and sometimes driverless returns 1 instead of printer uri.

Comment 6 Ben Cotton 2021-08-10 12:59:59 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.


Note You need to log in before you can comment on or make changes to this bug.