Re: [SL] Tracking Down Printing Problem

[Jeff R. <je...@jr...>]

Hi Rich

I agree, getting lpq resolved should also fix the sql problem. I don't 
think print to screen uses CUPS.

Can you confirm that CUPS is running?

I once had both CUPS and LPR installed on a machine and the lpr command 
would still work when CUPS was shut down. LPR had been installed on the 
machine when it was built and I had added CUPS later. So don't get 
tripped up into thinking that because a command line lpr works that CUPS 
is running.

Also, can you print a web page from within Firefox?

Jeff



Rich Shepard wrote:
> On Tue, 30 Dec 2008, Jeff Roberts wrote:
>
>   
>> Can you post what your sql-ledger.conf has under '# available printers'
>>     
>
> Jeff,
>
>    Sure. As I posted yesterday, the conf file hasn't been changed in four
> years.
>
>    From /usr/local/sql-ledger/sql-ledger.conf:
>
> # available printers
> %printer = ( laser_single   => 'lpr -P laser5_single>/dev/null 2>&1',
>               laser_duplex      => 'lpr -P laser5_duplex>/dev/null 2>&1',
>             );
>
>   
>> Are you using CUPS for your printing system? What does it call the printer?
>>     
>
>    Yup. Ever since it came out as a replacement for lprng (or whatever it was
> as the linux default back then). From /etc/cups/printers.conf:
>
> <DefaultPrinter laser5_duplex>
> Info Double-sided printing
> Location office
> DeviceURI socket://lj5:9100/
> State Idle
> StateTime 1228186929
> Accepting Yes
> Shared Yes
> JobSheets none none
> QuotaPeriod 0
> PageLimit 0
> KLimit 0
> OpPolicy default
> ErrorPolicy stop-printer
> </Printer>
> <Printer laser5_single>
> Info Single-sided printing
> Location office
> DeviceURI socket://lj5:9100
> State Idle
> StateTime 1229378152
> Accepting Yes
> Shared Yes
> JobSheets none none
> QuotaPeriod 0
> PageLimit 0
> KLimit 0
> OpPolicy default
> ErrorPolicy stop-printer
> </Printer>
>
>   
>> What computer is your printer connected to? The server? The desktop?
>> By parallel port? USB port? or on a local network by IP address?
>>     
>
>    It's a node on the network, connected by a JetDirect card. From
> /etc/hosts:
>
> 192.168.55.192  lj5.appl-ecosys.com     lj5
>
>   
>> The more data the better. I once had my server drop all of the printers
>> that it was supposed to see on the network through CUPS, the names had
>> changed and there was a problem with "concise names" or something like
>> that in the CUPS.conf file. It happened after years of normal operation
>> and all I had to do was make sure the printer names were consistent from
>> the computer where the queue was to the sql-server to the desktop and it
>> all started working again.
>>     
>
>    I suspect that this is a CUPS issue related to the distribution upgrade. I
> never before had to modify /etc/cups/client.conf, but after the upgrade
> nothing would go to the printer from that host.
>
>    When I type at the command line (even as root) 'lpq' I now get this:
>
> [root@salmo ~]# lpq
> lpq: Unable to connect to server
>
>    That's never before been the case. Also, lpr wasn't working. I tracked
> that down to the new need for another environment variable:
>
> export CUPS_SERVER=localhost
>
> which I had to put in ~/.bash_profile because specifying the server in
> /etc/cups/client.conf did not work. That the print queue status command
> still does not work suggests that there are still unresolved CUPS issues,
> one of which is affecting SL printing directly.
>
>    But, doesn't printing to 'screen' (really to a PostScript file on disk)
> also get processed through CUPS? Or does it bypass CUPS and use only
> ghostscript to produce the output file. And, if it is a CUPS issue, why will
> lpr work from the command line (or within xpdf or gv), but not printing
> directly from within SL? Curious minds want to know.
>
>   
>> Remember, also, that sql prints from the server not the desktop that you
>> access it from so while the lpr command may work from the desktop that's
>> not where it's called from. Does the lpr command work from the computer
>> where Apache is running?
>>     
>
>    Yup. The desktop is my combined server (httpd, postfix, etc.) and
> workstation.
>
> Many thanks,
>
> Rich
>
>