FS#44430 - [foomatic-db-engine] Adding new printer stalls, high CPU load foomatic list
Attached to Project:
Arch Linux
Opened by Bastien Traverse (Neitsab) - Wednesday, 01 April 2015, 15:55 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 28 July 2016, 19:59 GMT
Opened by Bastien Traverse (Neitsab) - Wednesday, 01 April 2015, 15:55 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 28 July 2016, 19:59 GMT
|
Details
Description:
When trying to add a new wifi printer (Epson_Stylus_SX420W, authenticated with the AP) through CUPS web interface: - the printer is immediately detected; - it is selectable under two entries : * one is "EPSON3B2202 (Epson Stylus SX420W) (EPSON Epson Stylus SX420W)" and matches the dnssd protocol (dnssd://EPSON3B2202%20(Epson%20Stylus%20SX420W)._printer._tcp.local/), as I'd later discover; * the other is "EPSON Epson Stylus SX420W (Epson Stylus SX420W)" and matches the lpd PASSTHRU version (lpd://192.168.1.200:515/PASSTHRU). - however, when I select either one and click on "Continue", the page just gets stuck loading while the process /usr/bin/perl /usr/lib/cups/driver/foomatic list hogs one CPU to the max. I then have to restart the process after waiting circa 1 minute and go through the whole process again. After retrying a few times and re-reading the CUPS wiki page I uninstalled foomatic-db{,-engine}, rebooted and tried again to add my printer. This time I could go past the "Continue" button immediately and see the protocol information for each entry, and then carry on with the installation by manually selecting the printer maker and model. If I'd select the dnssd entry it would fail to print because it set the location to localhost, but with the lpd entry I can finally print remotely without any troubles. I used to be affected by the similar cupsd bug I couldn't find a similar bug report on the upstream bugtracker (https://bugs.linuxfoundation.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=OpenPrinting&content=). Additional info: * package version(s): foomatic-db-engine 3:20150308-1, {lib,}cups 2.0.2-3, gutenprint 5.2.10-1 * config and/or log files etc. Unmodified Steps to reproduce: - Install cups, foomatic-db{,engine} and gutenprint - Log in CUPS web interface and try to add a new (wifi) printer - See whether /usr/bin/perl /usr/lib/cups/driver/foomatic list is taking a whole CPU. |
This task depends upon
cups 2.0.2-4, gutenprint 5.2.10-1, foomatic-db 3:20150308-1, foomatic-db-engine 3:20150308-1
This seems to be related to my problem and the problem isn't with gutenprint or foomatic. If I install gutenprint or foomatic but not both, I can view the printer list after clicking [Continue] on the "Name:Description:Location:" screen. If I install both I get an error in about a minute:
Add Printer a Error
Unable to get list of printer drivers:
Success
I think the web server is timing out. Maybe a little less beefy computer doesn't display a message at all. Whether there's a timeout fix or not a 30+ second delay to add a printer is too long. Someone needs to rethink how lots of printers can be accessed quickly. Having foomatic, gutenprint, and hplip on the same system just doesn't work. foomatic is the largest package so is the biggest contributor to the problem. I have hplip+gutenprint and I can see the printer list.
/usr/lib/cups/driver/foomatic list
that hangs. It is possible to test this command directly from the command line leaving out cups. I have done some debugging but with no definite answer. I have a simple python script that parse the output of strace (available here http://pastebin.com/DD9TKZNW ; to use it do: "strace /usr/lib/cups/driver/foomatic list |& python2 -u ./parse_strace" ) to list the file that the program open. I see that it hangs with the following file: rastertokmXXXXdl.xml. But it does not seem to be always the same file and moreover this file does not make part of gutenprint. The command "/usr/lib/cups/driver/foomatic list" does not hang in Ubuntu and give the expected list of drivers. I have only seen that Ubuntu ships less files than arch in (the equivalent of packages) foomatic-db and gutenprint but I am unable to find the real culprit.
You can fix the problem by removing the following files.
# gutenprint-ijs-simplified.5.2.xml |1504797
# gutenprint-ijs.5.2.xml |3046350
sudo rm -f /usr/share/foomatic/db/source/driver/{gutenprint-ijs-simplified.5.2.xml,gutenprint-ijs.5.2.xml}
It isn't locking up and it isn't stopping on any random printer. Due to the large file size, processing slows to a crawl when one of the above two files are hit. It will complete if you're willing to wait forever.
Due to the way hashes work in Perl, the printers are processed in slightly random order which is why you see random printers in the strace list.
#/usr/lib/perl5/vendor_perl/Foomatic/filters/xml/xmlParse.pm is owned by foomatic-db-engine 3:20151108-1
The problem is that xmlParse.pm is not coded well enough to handle XML files this large in a reasonable amount of time. On the way to pinpointing the problem I saw several "Shlemiel the painter's algorithms" which is likely to be the problem.
http://www.joelonsoftware.com/articles/fog0000000319.html
Conclusion: gutenprint is supplying some very large XML files which foomatic is unable to process within the time allowed by CUPS.
But Now, we can see some hang when we actually choose a ppd file because this ppd file must be generated. I can see a "hang" with /usr/lib/cups/driver/foomatic cat foomatic:Brother-HL-760-hpijs-pcl5e.ppd (when we choose the HL-760-hpijs-pcl5e.ppd file). This is less serious than previously because it does complete if we launch it by hand in about ~35 sec (on my Intel(R) Core(TM) i3-3240 CPU processor). Probably cups time out after 30s. @severach Do you have an idea how to increase the cups timeout?
I see Fedora and Debian/Ubuntu doing weird special update calls. Not sure if this really needed.
I've also applied a fix I've found in the Fedora spec:
# For gutenprint printers, use gutenprint-ijs-simplified.5.2.
perl -pi -e 's,>gutenprint<,>gutenprint-ijs-simplified.5.2<,' printer/*.xml
This looks related though Till at Debian doesn't seem to use it.
Our Gutenprint pkg currently ships this and now we should properly match it:
/usr/share/foomatic/db/source/driver/gutenprint-ijs-simplified.5.2.xml
/usr/share/foomatic/db/source/driver/gutenprint-ijs.5.2.xml
Confirmed - this is fixed now.