Hello all,

My workplace uses a primary server/secondary server + thin clients setup running SuSe Linux (A recent change from TurboLinux). We have Lexmark T522, 644, 652 and 634 model printers. We are using a Generic PPD file for all of these.

Cups seems to be functioning correctly on the primary server and the clients, however we have a persistant issue where the secondary server will stop printing successfully.

I have seen 3 distinct errors on various systems in the error logs.

1) Unable to open listen socket for address :::631 --Address family not supported by protocol

2) Unable to write uncompressed document data: Operation not permitted /usr/lib/cups/filter/gziptoany stopped wtih status 1

3) /usr/lib/cups/filter/foomatic-rip stopped with status 9.

These problems are frustratingly inconsistant. Sometimes the problem will remain for a time but eventually start working without any effort, others need to have the queue cleared, or cups restarted which typically corrects the problem but only fixes it for a short time or at best until the next reboot of the secondary system.

Now I am trying to research as much as I can about foomatic as this is the first time we have had to support CUPS. I encountered something very confusing. Our lexmark printers have a setting to handle Postscript and PCL data. So what im confused about is why we even need foomatic-rip. As explained by the foomatic website on linuxfoundations the whole point of foomatic is to take postscript data and convert postscript data into the printers native format based on the PPD. But if the printer can already handle Postscript data, then should it even be running through the filter which is generic ? Isnt this making it worse?

If this is true and we dont need to do this, is there a way to tell cups not to filter postscript data?

Thank you for any help you can give.

Hi I think the first problem (Unable to open listen socket for address :::631 --Address family not supported by protocol) has to do with this:
https://answers.launchpad.net/ubuntu...+question/7880
You must modify the Allow lines in /etc/cupsd.conf

Example:

<Location />
Order allow,deny
Allow localhost
Allow 192.168.1.0/255.255.255.0
</Location>

You can see more options with:
man cupsd.conf

I am being plagued by the same error currently:

Unable to write uncompressed document data: Operation not permitted /usr/lib/cups/filter/gziptoany stopped wtih status 1

did you ever find out why that is thrown? It happens approximately 10% of the time and almost always the job is resumable; Running RHEL 5 32 bit; Unfortunately RedHat has not been of much help in this case.

D [26/Jan/2011:12:11:50 -0800] [Job 18278] Wrote 4948 bytes of print data...

E [26/Jan/2011:12:11:50 -0800] [Job 18278] Unable to write print data: Broken pipe

D [26/Jan/2011:12:11:50 -0800] Discarding unused printer-state-changed event...

E [26/Jan/2011:12:11:50 -0800] [Job 18278] Unable to write uncompressed document data: Operation not permitted

D [26/Jan/2011:12:11:50 -0800] Discarding unused printer-state-changed event...

E [26/Jan/2011:12:11:50 -0800] PID 9706 (/usr/lib/cups/backend/socket) stopped with status 1!

E [26/Jan/2011:12:11:50 -0800] PID 9707 (/usr/lib/cups/filter/gziptoany) stopped with status 1!

Unfortunately not. The problems continue to arise. So far we are just using such terrible workarounds as resetting cups, rebooting the system, clearing the queue. They dont even always work.

I am sorry to hear Shodan30; On this side we are down to approximately (1) time daily when this error will occur or at best once every other day. On the particular server we have a good number of printers being managed (approximately 150) by this one specific server; One of the things that we did notice and which so far seems to be working for us (well I guess we will find out) is that in the last 2 times the printer that generated the error "Unable to write uncompressed document data: Operation not permitted" was one that was a dressed by cups using a DNS alias printer name rather the IP address of the printer. Switching to using the IP did not allow us to replicate the issue. I now have a number of printers that are referenced by IP and a number by their DNS alias name and monitoring to see if the issue can be replicated.

I have filled a bug request with the folks at RedHat but have not seen much activity on it yet.

I will keep you posted.

Well, the gziptoany filter problem is one of the least often ones occuring, mostly its a 'foomatic-rip failed' error. My web research has not found specific issues or definitions to the status codes, but most foomatic rip errors seem to be because of a bad driver. I'm going to try replacing the generic lexmark ppd driver we are using with one specific for the printer type on one of the stores that has a heavy reoccuring problem with this and see if it makes a difference. If this works, either we will need to try and modify the generic driver or code a way for the system to identify and use the correct ppd for its specific model since we have several in the field.