Bug 221194

Can you explain 'The print job terminates part way through' in more detail?  Is
the job cancelled by the user, or does it fail for some reason, and is there any
log message about it, etc?

The print job simply fails part way through, why I don't know.

Not a thing in /var/log/messages.

I'd like you to try to reproduce the problem if possible, and to capture the
debug logging information while doing so.  Here's how (all commands as root):

Edit /etc/cups/cupsd.conf and change the 'LogLevel' line to read:

LogLevel debug2

Edit /etc/foomatic/filter.conf and add this line at the end:

debug: 1

Disable SELinux so that the foomatic log can be written:

/usr/sbin/setenforce 0

Stop CUPS:

/sbin/service cups stop

Clear out the error log file:

>/var/log/cups/error_log

Start CUPS:

/sbin/service cups start

Now try to provoke the problem again, and when the job has crashed and
(optionally) foomatic-rip has eaten all the memory, I'd like to see:

1. The /var/log/cups/error_log file (you might need to compress it like 'bzip2
-c /var/log/cups/error_log >/tmp/error_log.bz2' first)

2. The /tmp/foomatic-rip.log file

3. The /tmp/foomatic-rip.ps file

Thanks.

Created attachment 144751 [details]
cups error log

Created attachment 144752 [details]
foomatic-rip.ps

Created attachment 144754 [details]
foomatic-rip.log

Running this:

(gs '-dBATCH' '-dPARANOIDSAFER' '-dQUIET' '-dNOPAUSE' '-sDEVICE=lx5000'
'-r600x600' '-dBitsPerPixel=4' '-sOutputFile=/dev/fd/3' '/dev/fd/0' 3>&1 1>&2)
<foomatic-rip.ps > /dev/null

seems to get stuck in an endless write loop, which would indicate a problem
either in the PostScript or in the lx5000 driver.

PostScript *looks* fine, so cloning this for ghostscript.

Leaving this original bug report for 'why does foomatic-rip buffer it all?'.

Created attachment 144813 [details]
Lexmark Z51 ppd

requested by someone else

Reported upstream via email.

The "lx5000" GhostScript driver seems to be really broken, even if foomatic-rip
would behave correctly, you cannot expect a correct printout. Try the "pbm2l7k"
driver. Are you able to print with that one? In this case I will change the
recommended driver for the Z51 on linuxprinting.org and mark the "lx5000" driver
as obsolete.

As long as the printer/driver does not use JCL/PCL (which is the case here)
foomatic-rip is not supposed to analyse and buffer the output of GhostScript, it
should pass it directly on to standard output. So the behavior is strange. I
will look into it.

Seems to be a Perl problem, as

cat foomatic-rip.ps | perl -e '$| = 1; pipe R, W; $pid = fork(); if ($pid)
{while (<R>) {print $_}} else {open (STDOUT, ">&W"); system "gs -dBATCH
-dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=lx5000 -r600x600
-sOutputFile=/dev/fd/3 /dev/fd/0 3>&1 1>&2"}' > x

eats up all the memory, too. And this command is a simple demonstration how
foomatic-rip works. We fork into two processes where one runs GhostScript and
another does some post-processing (in this simple example the second process
passes the data only to standard output, without actual processing). The data is
transported from the first to the second process by a pipe.

Or is there something wrong in the use of this method?

(In reply to comment #10)

> Try the "pbm2l7k" driver. 

It doesn't seem to work. 

I configured the Z51 to use this driver, but when I print, absolutely nothing
happens. The print job sits in the Gnome printer queue display marked
"Stopped?". I deleted the cups error.log and tried to print again, but nothing
was written to it.

If there is anything else you want me to try, let me know.

Colin: try enabling the queue with the 'cupsenable' command, or by using the
check-box shown in system-config-printer for 'Enabled'.  Perhaps the queue is
disabled due to the previous driver failing.

Till: here is a version using sysread and syswrite that doesn't seem to grow in
memory size.

cat foomatic-rip.ps | perl -e '$| = 1; pipe R, W; $pid = fork(); if ($pid){while
(sysread(R,$buf,1024)) {syswrite(STDOUT, $buf, length($buf))}} else {open
(STDOUT, ">&W"); system "gs -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE
-sDEVICE=lx5000 -r600x600 -sOutputFile=/dev/fd/3 /dev/fd/0 3>&1 1>&2"}' > x

Thank you very much, I will change foomatic-rip appropriately.

(In reply to comment #13)

> try enabling the queue with the 'cupsenable' command, or by using the
> check-box shown in system-config-printer for 'Enabled'.  Perhaps the queue is
> disabled due to the previous driver failing.

For whatever reason, the pbm2l7k just doesn't work here. Jobs get queued but
nothing happens. For the time being I am using the lx5000, albeit very gingerly.

Colin: would you mind filing a separate bug about the pbm2l7k driver?  Choose
'ghostscript' as the component.  Thanks.

Can you replace your /usr/bin/foomatic-rip file by this one:

http://www.linux-foundation.org/~till/tmp/foomatic-rip

and then try again to print? Does this solve the problem?

Applied the fix upstream:

http://www.linuxprinting.org/download/foomatic/foomatic-filters-3.0-20070220.tar.gz

But please test my file posted earlier to see whether this really solves the
problem.

I am currently running foomatic-3.0.2-47.2.fc7 and this bug no longer occurs.
Thanks!

Great, glad the update fixed it.  Thanks for re-testing!