Bug 1052203 - Unable to add Network Printer & GUI freezes while Searching for Drivers
Summary: Unable to add Network Printer & GUI freezes while Searching for Drivers
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-printer
Version: 20
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1052982 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-13 13:46 UTC by Jorge Fábregas
Modified: 2014-10-10 16:02 UTC (History)
12 users (show)

Fixed In Version: system-config-printer-1.4.5-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-10 00:24:06 UTC


Attachments (Terms of Use)
Adding printer with default tool (5.90 MB, video/webm)
2014-01-13 13:46 UTC, Jorge Fábregas
no flags Details
Adding printer with system-config-printer (2.56 MB, video/webm)
2014-01-13 13:47 UTC, Jorge Fábregas
no flags Details
patch fixing hiding of the message dialog (608 bytes, patch)
2014-01-15 15:35 UTC, Marek Kašík
no flags Details | Diff
/scp-dbus-service-do-not-hang-when-searching-openprinting-for-drivers.patch (3.95 KB, patch)
2014-06-26 16:00 UTC, Till Kamppeter
no flags Details | Diff

Description Jorge Fábregas 2014-01-13 13:46:24 UTC
Created attachment 849370 [details]
Adding printer with default tool

Description of problem:  Tried to add my network printer on 192.168.0.3 (Xerox Phaser 3250/DN) with the default printing tool but the window for "Searching for Drivers" gets stock on the middle of the screen (stays there forever).  While the printer seems to be added it doesn't work (please see attached video 01-gnome-print-settings.webm).

I then proceeded with system-config-printer and had no problems (see attached 02-system-config-printer.webm)


Version-Release number of selected component (if applicable):
# rpm -qa | grep cups print control...

control-center-3.10.2-3.fc20.x86_64
cups-1.7.0-9.fc20.x86_64
gutenprint-cups-5.2.9-14.fc20.x86_64
bluez-cups-5.13-1.fc20.x86_64
python-cups-1.9.63-4.fc20.x86_64
cups-filesystem-1.7.0-9.fc20.noarch
cups-pk-helper-0.2.5-2.fc20.x86_64
cups-filters-libs-1.0.41-4.fc20.x86_64
cups-libs-1.7.0-9.fc20.x86_64
cups-filters-1.0.41-4.fc20.x86_64
system-config-printer-1.4.3-2.fc20.x86_64
system-config-printer-libs-1.4.3-2.fc20.noarch
libchromaprint-1.0-1.fc20.x86_64
system-config-printer-udev-1.4.3-2.fc20.x86_64
gutenprint-cups-5.2.9-14.fc20.x86_64
gutenprint-5.2.9-14.fc20.x86_64
fprintd-pam-0.5.1-1.fc20.x86_64
fprintd-0.5.1-1.fc20.x86_64
libfprint-0.5.1-1.fc20.x86_64



How reproducible: Always


Steps to Reproduce:
1. See attached video
2.
3.

Actual results:
Printer is not correctly installed

Expected results:
Printer gets installed

Additional info:

Comment 1 Jorge Fábregas 2014-01-13 13:47:17 UTC
Created attachment 849371 [details]
Adding printer with system-config-printer

Comment 2 Tim Waugh 2014-01-13 15:48:08 UTC
First thought: with system-config-printer you are just telling it where/how to print, rather than letting it work it out like control-center has to.

Maybe you could try looking in the "Network printers" part of the device list to see if it found the device like control-center did?

Maybe you should let it try working out which driver to use, to see if it has the same problem control-center does?

The behaviour in the control-center video is certainly odd though. I'm not sure what the 'Installing' state means as opposed to 'Configuring'. It may take several minutes to find and install the driver though -- how long did you leave it?

Comment 3 Jorge Fábregas 2014-01-13 20:09:49 UTC
On system-config-printer...I tried it initially but it doesn't "autodiscover" it so I had to manually specify protocol and ip.

Regarding the driver...It doesn't find it.  I'm presented with the "Choose Driver" window with the 3 options:  Select printer from database, Provide PPD, Search for printer driver to download.  That's where I provide my PPD file.

Regarding the gnome tool I left it there for about 7 minutes...

Comment 4 Marek Kašík 2014-01-15 12:51:51 UTC
Hi Jorge,

could you paste here what "lpinfo -l -v" returns for the printer under root?

Regards

Marek

Comment 5 Marek Kašík 2014-01-15 15:34:48 UTC
It seems that this is a problem in system-config-printer. Specifically in its DBus method GetBestDrivers. It doesn't close the message dialog when the search is over.
I think that since the message dialog is iterated manually it needs also some iterations to hide so I tried to add some iterations after the hide and it closes successfully (see the attached patch).

You can reproduce this by running:

gdbus call --session --dest org.fedoraproject.Config.Printing --object-path /org/fedoraproject/Config/Printing --method org.fedoraproject.Config.Printing.GetBestDrivers "MFG:Xerox;CMD:HBPL;MDL:Phaser 3250;DES:Xerox Phaser 3250;CLS:PRINTER;STS:AAARBAD/AP8AAAAAAAQAAWQDZANkA2QDAAAAAAADUAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAQDA==;" "Xerox Phaser 3250 (XRX0000AAAFC993)" "dnssd://Xerox%20Phaser%203250%20(XRX0000AAAFC993)._pdl-datastream._tcp.local/"

The problem shows after second run of this command.

Unfortunately, the patch doesn't help when you run the command three times (just when you run it twice).

Comment 6 Marek Kašík 2014-01-15 15:35:59 UTC
Created attachment 850570 [details]
patch fixing hiding of the message dialog

Comment 7 Marek Kašík 2014-01-15 15:36:53 UTC
*** Bug 1052982 has been marked as a duplicate of this bug. ***

Comment 8 Jorge Fábregas 2014-01-16 00:59:43 UTC
Marek,

Here's the output:

Device: uri = lpd
        class = network
        info = LPD/LPR Host or Printer
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = socket
        class = network
        info = AppSocket/HP JetDirect
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = http
        class = network
        info = Internet Printing Protocol (http)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = ipp
        class = network
        info = Internet Printing Protocol (ipp)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = https
        class = network
        info = Internet Printing Protocol (https)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = hp
        class = direct
        info = HP Printer (HPLIP)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = serial:/dev/ttyS0?baud=115200
        class = serial
        info = Serial Port #1
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = ipps
        class = network
        info = Internet Printing Protocol (ipps)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = beh
        class = network
        info = Backend Error Handler
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = smb
        class = network
        info = Windows Printer via SAMBA
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = hpfax
        class = direct
        info = HP Fax (HPLIP)
        make-and-model = Unknown
        device-id = 
        location =

Comment 9 Netbulae 2014-01-16 12:06:02 UTC
And this is my info (duplicate bug)

Device: uri = ipps
        class = network
        info = Internet Printing Protocol (ipps)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = beh
        class = network
        info = Backend Error Handler
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = http
        class = network
        info = Internet Printing Protocol (http)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = https
        class = network
        info = Internet Printing Protocol (https)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = lpd
        class = network
        info = LPD/LPR Host or Printer
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = socket
        class = network
        info = AppSocket/HP JetDirect
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = ipp
        class = network
        info = Internet Printing Protocol (ipp)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = hp
        class = direct
        info = HP Printer (HPLIP)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = serial:/dev/ttyS0?baud=115200
        class = serial
        info = Serial Port #1
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = smb
        class = network
        info = Windows Printer via SAMBA
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = hpfax
        class = direct
        info = HP Fax (HPLIP)
        make-and-model = Unknown
        device-id = 
        location = 
Device: uri = dnssd://MF8030-393462._pdl-datastream._tcp.local/
        class = network
        info = MF8030-393462
        make-and-model = Canon MF8030
        device-id = MFG:Canon;MDL:MF8030;FZY:0;
        location =

Comment 10 Tim Waugh 2014-04-30 11:20:54 UTC
Thanks for the patch.

It looks like the remaining problem is because of the openprinting driver download support Till added last year. Really that needs to be re-factored into the ppdsloader, avoiding the need to run an inner main loop.

Comment 11 Till Kamppeter 2014-04-30 13:37:28 UTC
When the proble shows after the second (with patch after the third) run, it looks like that on the first run some structure is set up which should get removed in the end but actually does not get removed, perhaps main loops which get concurrently running (only a guess).

Comment 12 Tim Waugh 2014-05-01 14:09:15 UTC
Yes, it does look like that. I couldn't track down what was wrong.

I'm sure re-factoring that code would fix it, but I don't have the time to look at that right now (anyone else?). In the mean time I can disable the openprinting driver download part of the D-Bus service.

Comment 13 Till Kamppeter 2014-06-26 16:00:21 UTC
Created attachment 912477 [details]
/scp-dbus-service-do-not-hang-when-searching-openprinting-for-drivers.patch

The problem seemed to be the "Searching for drivers" pop-up which was opened without having an actual new-printer dialog as parent.

The previous patch only fixed the "Searching for drivers" pop-up not diosappearing on the second run. Independent of this, the first two runs delivered the correct answer and any further run was hanging, leading to a timeout of the "gdbus call ..." command, requiring manually killing the scp-dbus-service process.

The attached patch solves both problems, once containing the previous patch and second, not popping up the "Searching for drivers" window and with this also not attending the GTK events (no "Gtk.main_iteration()" calls) if we are running NewPrinter in the "download_driver" dialog mode (which means that we have called it only for finding and downloading a driver via OpenPrinting).

Please check this patch. It should eliminate the hang, but it also removes the "Searching for drivers" pop-up (here the client should take care of telling the user that the search will take some time).

The patch will not change the behavior of the system-config-printer GUI, doing the driver check in s-c-p, the "Searching for drivers" pop-up will still appear.

Comment 14 Tim Waugh 2014-07-03 12:21:00 UTC
I don't think that gets to the heart of the problem. It does solve the test case as presented, but the basic issue seems to be that any UI interaction can cause a deadlock.

I see the same deadlock, for instance, if I tweak the search to look for a Ricoh Aficio 3260C -- a model for which openprinting.org offers PPDs. It does the query, and hangs once it tries to present the dialog. (It worked a couple of times.)

Comment 15 Fedora Update System 2014-07-04 16:31:56 UTC
system-config-printer-1.4.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/system-config-printer-1.4.5-1.fc20

Comment 16 Fedora Update System 2014-07-05 14:55:52 UTC
Package system-config-printer-1.4.5-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing system-config-printer-1.4.5-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8100/system-config-printer-1.4.5-1.fc20
then log in and leave karma (feedback).

Comment 17 Mikhail 2014-07-07 03:32:23 UTC
(In reply to Tim Waugh from comment #14)
> I think I can answer those two:
> 1. The manufacturer's driver sends PostScript, so the printer has to do the
> rendering itself and may take time to do so, whereas gutenprint renders the
> job before sending it to the printer. That's my guess at why.
> 2. It does get installed for me, and used by default. The reason it didn't
> for you is most likely bug #1052203
> 
> There's another question actually: is the bad quality/extra page issue due
> to Firefox reprocessing the PDF in some way, or due to some job option it's
> providing?
> 
> The way to find out is to take a look at the job options for one of the test
> jobs you've tried.
> 
> Using system-config-printer (the "Print Settings" application), could you
> please right-click on the printer and select View Print Queue, then click on
> the 'Show completed jobs' button (2nd one on toolbar).
> 
> Right-click on one of the jobs sent from Firefox, and select 'View
> Attributes'. Could you please maximise that window to the height of the
> screen and take a screenshot? (Might need to take more than 1)
> 
> Thanks.


After update still installer gutenprint driver by default
Demonstration: https://drive.google.com/file/d/0B0nwzlfiB4aQOWd3Ukp0RmxFRFk/edit?usp=sharing

Comment 18 Mikhail 2014-07-07 19:05:27 UTC
[mikhail@localhost ~]$ rpm -q system-config-printer
package system-config-printer is not installed
[mikhail@localhost ~]$ rpm -qa | grep system-config-printer
system-config-printer-libs-1.4.5-1.fc20.noarch
system-config-printer-udev-1.4.5-1.fc20.x86_64

Comment 19 Fedora Update System 2014-07-10 00:24:06 UTC
system-config-printer-1.4.5-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Till Kamppeter 2014-07-19 15:51:19 UTC
Generally, openiong windows, performing OpenPrinting queries, or installing a driver out of the scp-dbus-service is not problematic with the currecnt implementation. What is broken is creating an instance of the NewPrinterGUI class and opening the new printer wizard only delayed or not at all.

I come to this conclusion by triggering the full new printer wizard out of the scp-dbus-service running a command like

scp-dbus-service --client file:/tmp/printout --devid 'MFG:EPSON;MDL:EP-805A Series;'

This opens the wizard first, then searches for local drivers, fails as this printer is locally unsupported, then looks it up on OpenPrinting and opens the download interface. This I can repeat arbitrarily many times without scp-dbus-service hanging (repeat within 30 sec after previous run). If I wait more than 30 sec without repeating, scp-dbus-service closes as expected.

The problem of the wizard (driver download page) not starting up and/or the scp-dbus-service getting unresponsive I only get by calling a D-Bus method which only searches for driver (either local + OpenPrinting or OpenPrinting only) and then opens the wizard for download (and only for that) if needed. This leads to the wizard not opening and then scp-dbus-service hanging and even if no download is possible (query printer which does not exist at all) and so no attempt of opening the wizard takes place leads to scp-dbus-service hanging.

Comment 21 Till Kamppeter 2014-07-20 09:21:42 UTC
When doing the tests leading to the observations of my previous comment, I did not only use the GetBestDrivers method (which has its own inner main loop) but also the DownloadDriverForDeviceID (which does not have an own main loop).

Also the OpenPrinting query works when the new printer wizard window is opened immediately.

What needs to get checked is whether either the instance of NewPrinterGUI gets destroyed/freed when the request is completed or whether subsequent requests re-use the existing instance instead of opening a new instance every time.

What I am thinking about what could work better is that scp-dbus-service calls system-config-printer via command line with special options for the different interactive (window-opening) tasks. So with this we have for sure cleaned up after each task and tasks are not interfering with each other. WDYT?

Comment 22 Tim Waugh 2014-07-31 16:41:09 UTC
Thanks for investigating this some more. However, I think I'd rather fix the locking problem, as it might have implications for other parts of the D-Bus service.

I looked into whether the NewPrinterGUI object gets properly freed after each call, and you're right, it doesn't. I've fixed that now.

I've pushed a 'dbus-fixes' branch which contains these fixes:
* re-write the bits that used an inner loop in scp-dbus-service.py so they are asynchronous instead
* call 'destroy' on the NewPrinterGUI object to make sure it gets cleaned up
* don't re-create the global FetchedPPDs object, just make it reload PPDs

I still see the same problem. After the second iteration of the call from comment #5, the D-Bus service is stuck trying to grab the GDK lock.

It just needs a bit of debugging on why the lock is getting stuck there.

Comment 23 Tim Waugh 2014-08-01 18:02:28 UTC
I think the reason for the deadlock is that nextNPTab() is having to call Gtk.events_pending()/Gtk.main_iteration() in several places, but it can't know whether it's safe to do so.

I've pushed a commit on the dbus-fixes branch that removes those calls, and I no longer see deadlocks.

The real fix will be to re-work the openprinting driver search code (and parts of nextNPTab) so that it is properly event-driven, i.e. it starts a query going, and when that query finishes a signal is emitted which a handler can pick up to deal with the query result.

Comment 24 Till Kamppeter 2014-09-04 16:54:07 UTC
I have now tried system-config-printer without any patches ad it locks up immediately, probably on the attempt to open the wait pop-up window. Thereseems to be something wrong with scp-dbus-service having been changed to the GTK main loop to fix bug 1116756.

Comment 26 Till Kamppeter 2014-09-05 11:58:38 UTC
Tim, thank you very much. The immediate crash is fixed now.

Comment 27 Mario Sanchez Prada 2014-09-23 15:33:46 UTC
I've reproduced this same issue locally (system-config-printer 1.4.3), and can finally install the printer without deadlocks after applying the patches in the dbus-fixes branch (which now includes the one in comment #25).

However, I can't see the "Searching for drivers" dialog anymore, but just the gnome-control-center main window in an insensitive state for the time that scp-dbus-service.py is working, returning the control the user as soon as it's done.

I guess that's perhaps expected (the "Searching" dialog not showin up) as those patches have not been merged yet (so I believe they are experimental stuff at the moment), but asking anyway just in case.

Thanks in advance

Comment 28 Tim Waugh 2014-09-25 15:26:40 UTC
I haven't been able to look at this yet but I hope to get to it soon.

Comment 29 Tim Waugh 2014-10-10 16:02:34 UTC
I've fixed this upstream now.

There are a sequence of cupshelpers.openprinting calls each time we want to perform a search. I've grouped these together into an OpenPrintingRequest GObject, one which emits signals when it has finished.

The two different places we do this from now each connect their signal handlers as appropriate, and nextNPTab does not block waiting for the request to complete.

Till, I've removed some code to do with downloading binary packages as I wanted to get it working correctly for PPD files in the first place. Perhaps you could take a look at the places where installdriverpackage had previously been called?

The upstream commit is this one:
  330bfe3570d9821eadc72066cf6371dd71216aa7


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