Bug 81706

Does 'lpr file.ps' show the same behaviour?  I suspect this is a kghostview bug.

Yes, same problem with  'lpr file.ps'. 
Can you at least let me know what rpm's are involved so I can try to install 
printing services for RH 7.3 or 7.2 and see if that solves the problem 

Precisely which model of HPLJ5 is it?  The recommended drivers to use vary:

LaserJet 5:      lj5gray
LaserJet 5/5M:   omni
LaserJet 5L:     ljet4
LaserJet 5M:     Generic PostScript
LaserJet 5MP:    Generic PostScript
LaserJet 5P:     ljet4
LaserJet 5P/5MP: omni
LaserJet 5si:    lj5gray
LaserJet 5si MX: omni

I'd suggest you try different drivers to see which gives what output.

I have a LaserJet 5P.  I've tried some other drivers as you suggested.  Here 
are the results: 
 
LJ5P gimp-print: works OK, but printing is a little too light 
LJ5  lj5gray:    lpq shows job as active, then done, but nothing gets printed 
LJ5P/5MP omni:   same problem as with ljet4, although the first time I got it 
to print 20 pages.  After that, it always stalls after a few pages, like 
ljet4. 
 
Thanks for your help! 

After you get to the 'stalled' stage, can you see if there is an lpq.0 file in
/var/spool/lpd/<printername>?  Does it contain any useful messages?

Created attachment 89588 [details]
lpd log file?

Here is the file you requested

I have enclosed /var/spool/lpq/lp0/lpq.0. 
I don't see anything particularly useful in it, but I don't know much about 
lpd. 

Please try this:

gs -dBATCH -dSAFER -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=out.prn mypostscriptfile.ps

(all one line)

Then:

cat out.prn > /dev/lp0

(as root)

Does that work?

This seems to work fine.  I have just printed a document with 20+ pages. 

Okay.  With that out.prn (that works), please try this:

perl -e "while (\$line = <>) { my \$b = \"\"; \$match |= ( \$line =~
s/\x1b&l\d+A/\$&\$b/ ); \$line =~ s/\x1b&l0H/\$b/g; print \$line }" < out.prn >
mod.prn

(all one line, again)

Then do: 'cmp out.prn mod.prn' (just out of curiosity).

See if 'cat mod.prn > /dev/lp0', as root, still works.

I tried: perl -e "while (\$line = <>) { my \$b = \"\"; \$match |= ( \$line 
=~s/\x1b&l\d+A/\$&\$b/ ); \$line =~ s/\x1b&l0H/\$b/g; print \$line }" < 
out.prn > mod.prn 
 
I got lots of messages of this form: 
 
Malformed UTF-8 character (unexpected end of string) at -e line 1, <> line 
9740. 
 
cmp out.prn mod.prn reports no differences, so I didn't try printing again. 

Please try adjusting the queue using redhat-config-printer, and set it to go to
a custom device (rather than /dev/lp0).  Set the custom device to be '/tmp/lp0',
and then create it like this:

> /tmp/lp0
chmod a+w /tmp/lp0

Then print as normal: the output will go to /tmp/lp0 rather than the printer. 
Then try 'cat /tmp/lp0 > /dev/lp0' as root.

I'm trying to figure out if it's the method of transferring the data to the
printer that's the problem, or the actual data that we're sending it.

What you suggested (change printer to /tmp/lp0 and print from file with 'cat
/tmp/lp0 > /dev/lp0' works fine.  Sorry about the delay in replying.  The reason
for it is that since I have tried that test, I have been unable to reproduce the
problem I had.  In general, it seems that whenever I use redhat-config-printer
to change something, I seem to get some more printing out of the system. 
Perhaps this is because of some memory leak which gets fixed when I restart the
lpd, I don't know.  However, this time since I set it back to /dev/lp0 with
ljet4 I haven't been able to make it fail, which is good in some ways and bad in
others.

Let me wait a few days until I run into this bug again; I will then report again.

OK; I got lpd to fail again when printing to /dev/lp0, but seems to work OK 
when printing to /tmp/lp0 as you suggested.  The error for /dev/lp0 takes a 
little while to happen after using redhat-config-printer, but after the first 
time it happens, it then happens consistently.  Let me know how to proceed. 

So it seems to be the method that lpd is using to transfer the data that is the
problem, rather than anything in the data itself.

The next step is to figure out what's going wrong.  What I'd like you to do is,
once lpd has got into this state, attach 'strace' to it like this:

strace -p 1815

(substitute the right PID in place of 1815: it's the child lpd process in 'ps
axf' output.)

Please attach that strace output, so we can see what's going on.  Thanks.

This is what I got (interestingly, printing resumed once I did strace -p 
9130): 
 
 9114 ?        S      0:00  \_ lpd (Server) 'lp0' 
 9115 ?        S      0:00      \_ lpd (Worker - Print) 'lp0' 
 9116 ?        S      0:00          \_ /bin/bash 
/usr/share/printconf/util/mf_wr 
 9127 ?        S      0:00              \_ /bin/bash 
/usr/share/printconf/util/m 
 9128 ?        S      0:00                  \_ /usr/bin/perl 
/usr/sbin/lpdomatic 
 9129 ?        S      0:00                      \_ /usr/bin/perl 
/usr/sbin/lpdom 
 9130 ?        S      0:07                          \_ /usr/bin/perl 
/usr/sbin/l 
 9131 ?        S      0:00                          \_ sh -c 
foomatic-gswrapper  
 9132 ?        S      0:00                              \_ sh -c gs '-dBATCH' 
'- 
 9134 ?        S      0:01                              |   \_ gs -dBATCH 
-dSAFE 
 9133 ?        S      0:00                              \_ perl -e while 
($line  
 
select(10, [7 8 9], NULL, NULL, {585, 915957} 
 
 <unfinished ...> 
[root]/home/anash>strace -p 9114 
[root]/home/anash>man strace 
[root]/home/anash>strace -p 1734 
select(10, [7 8 9], NULL, NULL, {543, 513639} 
 <unfinished ...> 
[root]/home/anash>strace -p 9114 
[root]/home/anash>strace -p 9115 
read(7,  <unfinished ...> 
[root]/home/anash>strace -p 9116 
wait4(-1, 
 <unfinished ...> 
[root]/home/anash>strace -p 9127 
wait4(-1,  <unfinished ...> 
[root]/home/anash>strace -p 9127 
wait4(-1,  <unfinished ...> 
[root]/home/anash>strace -p 9128 
write(4, "(in)e Fi(F)43 b Fk(and)30 b(w)m("..., 60 <unfinished ...> 
[root]/home/anash>strace -p 9128 
write(4, "(in)e Fi(F)43 b Fk(and)30 b(w)m("..., 60 <unfinished ...> 
[root]/home/anash>strace -p 9129 
wait4(9131,  <unfinished ...> 
[root]/home/anash>strace -p 9130 
write(1, "\3\200\34\34\36\0169\7\0002\1\300\33*b18W\37\247\17<\1"..., 370) = 
370 
write(1, "\300\6\37\36\200\1>\n", 8)    = 8 
write(1, "\3\3\376\10\7\26\300\33*b11W\37\232\300\37\27\360\16\374"..., 101) = 
101 
write(1, "\0\2\374\2\34\5\37\26\360\33*b19W\37\231\17\r\0\37\0\3"..., 29) = 29 
write(1, "\17\r\0\24\1\33*b15W\37\231\16\2\7\37\10\37\37\35\177\r"..., 79) = 
79 
write(1, "\36\3\370\10>\25\0\33*b9W\37\231\34\37\'\360\37\17\34\33"..., 145) = 
145 
write(1, "\0\6\0\5|\3\37!\1\376*\7\360\3|\33*b54W\37\234\37\t\374"..., 268) = 
268 
write(1, ">\2\200F?\0\17\21?l\3\200\371\340*\17\200\1\340\33*b43"..., 84) = 84 
write(1, ">)?\0\1\374\3|r\377\377\377\370\4\340\2\36\1\376\v\370"..., 36) = 36 
write(1, ">\5>\33*b48W\37\245\1\4\0\1\0\n", 17) = 17 
write(1, "|\2\370\6\177\1\1\4~\25\377\3\7\3\34\1\374*\1\360\2\340"..., 35) = 
35 
write(1, "|\2\370\2?\33*b31W\37\234\177-\1\376\v\374\t\376\231\370"..., 31) = 
31 
write(1, "\3)\3\370\23\177-\1\376\v\374\33*b32W\37\242\300\6\17,"..., 235) = 
235 
write(1, "\17)\17\360\2\360\350\7\377\377\377\377\377\377\376\6\340"..., 24) = 
24 
... 

Okay, I think that's a good clue.  9130 I think is 'lpdomatic'.  Can you try to
catch it again, but this time rather than stracing it find out what 'ps
-opid,cmd,wchan -afx' says.  The last name on each line is the place in the
kernel where the process it waiting.

Also, it would be useful to get a strace log from _before_ lpdomatic hangs (and
including the hang), if that's possible.

We no longer ship LPRng.