System :: Trying to get CUPS to work



I'm still struggling with this - I can print reliably after compiling/installing hplip but I cannot print after making an extension out of hplip. I tried two methods:

1. Install a number of debs using dpkg and compile hplip-0.9.5 and make an extension from the files installed. When I load the extension after reboot and try to install a printer, things go OK up until I give the printer a name in the cups admin client and then I get this message:
Quote
Request Entity Too Large
The request is too large for this server to process.HTTP/1.1 413 Request Entity Too Large Date: Fri, 29 Jun 2007 19:09:52 GMT Server: CUPS/1.1 Content-Language: en_US Upgrade: TLS/1.0,HTTP/1.1 Connection: close Content-Type: text/html Content-Length: 168
Request Entity Too Large
The request is too large for this server to process.


2. Install a number of debs using dpkg and compile hplip-0.9.5 and install a printer (works OK) and make an extension out of the files installed. When I load the extension after reboot and try to print a test page I get this message:
Quote
[on the printed test page]
**** Unable to open the initial device, quitting.

[in /var/log/cups/error_log]
I [29/Jun/2007:18:59:26 +0000] Job 7 queued on 'OfficeJetG85' by 'root'.
I [29/Jun/2007:18:59:26 +0000] Started filter /usr/lib/cups/filter/pstops (PID 1588) for job 7.
I [29/Jun/2007:18:59:26 +0000] Started filter /usr/lib/cups/filter/foomatic-rip (PID 1589) for job 7.
I [29/Jun/2007:18:59:26 +0000] Started backend /usr/lib/cups/backend/hp (PID 1590) for job 7.
E [29/Jun/2007:18:59:27 +0000] PID 1589 stopped with status 3!
I [29/Jun/2007:18:59:27 +0000] Hint: Try setting the LogLevel to "debug" to find out more.


Does anybody have an idea what the problem might be?
When I used to print from my "brother" printer, I did not use cups (they have some great native linux drivers), but my only problem was permission on the temporary printer spool.  Searching around seems to suggest this as well for cups... in "/var/spool/cups".  You might have to manually create it? (maybe easier to just archive it)

Did you try
Quote
Try setting the LogLevel to "debug"
If I understand corectly, you're suggesting to change the permissions on /var/spool/cups to dsl/staff, is that correct?

I'd love to set the log level to debug, but how?
Quote
If I understand corectly, you're suggesting to change the permissions on /var/spool/cups to dsl/staff, is that correct?
Well, that might work as well.  Just giving write permissions (at a minimum I think it was) to everyone should do the trick.

Quote
I'd love to set the log level to debug, but how?
I think this is what it means... see www.cups.org/cups-help.html
Quote
Switch on the "debug" mode in the LogLevel directive for your CUPS daemon. Edit /etc/cups/cupsd.conf (or wherever this configuration file is installed in your case) to have the line "LogLevel debug" there. Then restart your CUPS daemon /etc/software/init.d/cups start (the command may be customized by your Linux distribution; f.e. SuSE will take "rccups start").

Now print a job. Watch what is written to your CUPS error log. It normally sits in /var/log/cups/error_log. In debug level, nearly every action of the CUPS daemon is logged. You can see which filters and backends are called in which order. Very often you'll get a hint about what is missing for the print job to succeed.
Thanks - once I changed the log level to debug in /etc/cupsd.conf, I saw this:

Code Sample

D [30/Jun/2007:18:00:05 +0000] [Job 3] GNU Ghostscript 7.05: Could not open the scratch file /var/spool/cups/tmp/gs_AStYqN

Creating an empty directory /var/spool/cups/tmp solved the problem - you'd think cups would be smart enough to write it's own /tmp directory...

Now I can restore an extension on my laptop and get things working. I thought his was fixed, but when I load an extension on my ancient desktop and start the cupsys daemon, the cpu usage goes to 100% and never returns (even if I stop cupsys) and thus the connection to http://localhost:631 is refused...

Edit
----
Got it - deleting the cups and hplip files in /etc/rc0.d - /etc/rc6.d seems to have stopped the 100% cpu thing.

Edit 2
------
But only in dsl format, a unc made from the dsl gives the same "connection refused" error - I guess that'll have to do for now.
Next Page...
original here.