CUPS Ghostscript Stuck Forever Airprint

[foodie]

Anybody else have this problem?

When ghostscript is invoked by CUPS, it hangs forever until CUPS terminates the job based on the timeout. (The CUPS web console says "Processing" for the job status)

After some debugging, it seems that the hanging occurs when a font issue occurs. In other words, if I print an image, it will print fine. I have the gsfonts package installed and I know that the ghostscript package has default fonts included as well. I haven't touched the ghostscript files at all.

I'm using a STOCK installation of the latest kernel, packages (cups, gutenprint, avahi, ghostcript, etc), and dependencies. [pacman -Syu to install]

Using top, I see the 'gs' process using 90+% of cpu when the print job is stuck.

Enabling debug and debug2 in the cupsd.conf config didn't yield anything fruitful other than the fact that it seems that it's waiting for gs to complete.

**** Easiest way to reproduce ->>> In the CUPS web console, print a test page. [Fresh installation of latest packages] The test page will stay in processing forever until it times out in a few hours. ****

I've confirmed the same issue whether I print to the physical printer or the cups-pdf printer.

Anybody have a solutions for this?

I bought the Pogoplug E02 to act as a print server for the LAN and iOS (via Airprint).

It would be great to get this working. Thanks in advance for any help you can give!

[WarheadsSE]

Instant reaction guess: massive floating point math. Thus, falter.

[pepedog]

It's probably a filter swallowing up all ram. My zyxel nsa320 has twice as much ram, plus good size swap, and can't cope.
My odroid U2 has no problems

[foodie]

Thanks for the responses.

I'm a bit surprised it could be RAM related in the sense that it's choking on a very simple page: the CUPS test page print. I just didn't expect that could be an issue for that page.

In fact, this page with the same setup [Pogoplug E02 +CUPS] advocates testing with the test print from the CUPS web console to make sure your printer drivers work:
http://blog.qnology.com/2013/03/tutorial-pogoplug-e02-with-arch-linux.html

Appreciate the responses. Maybe it's a RAM issue, but I certainly hope not. Would really love to get this Pogoplug E02 set up as a reliable print server.

Thanks everyone!

[WarheadsSE]

I still start to think it is not a RAM issue but a CPU doing _massive_ amounts of floating point emulation. This takes a while.

[grayman4hire]

At some point in the past the tutorial was working correctly.

Now with a fresh ALARM install it is no longer working. Not exactly sure what's going on.

gs is stuck at 90%+ and the print job is stuck at processing.

[grayman4hire]

Just a quick update, even though I was not able to print a test page from CUPs, I was still able to AirPrint on some occasion (it wasn't very consistent).

After spending way more time than I should have trying to troubleshoot the AirPrint issue under Arch, I switched to Debian. Was able to get it up and running fairly quickly.

[pepedog]

My AirPrint stopped working too, very unreliable. I deleted the avahi service file and created again with script and all is well (odroid U2)

[grayman4hire]

Hi @pepedog,

Is your arch linux up to date? Do you use GhostScript? Do you experience the same issue when printing a test page? What printer model and drivers are you using? Thanks

Weird why regenerating the service file would do anything.

gray

[pepedog]

Apart from kernel, up to date. Ghostscript is installed.

Got brother hl2030, after facing x86 only drivers a method of getting it working was found. I immediately duplicated on zyxel nsa320 and it didn't work (it was visible in IOS). On the odroid it became flakey showing up in iOS (reboots helped), eventually after months not show ever.
Recreating service only thing that restored it. Windows printing never a problem