Re: [SL] Tracking Down Printing Problem

[Rich S. <rsh...@ap...>]

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

-- 
Richard B. Shepard, Ph.D.               |  Integrity            Credibility
Applied Ecosystem Services, Inc.        |            Innovation
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863