Bug 81706 - lpd stalls after 2 1/4 pages of postscript
Summary: lpd stalls after 2 1/4 pages of postscript
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: LPRng
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-13 03:38 UTC by Need Real Name
Modified: 2007-04-18 16:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-16 16:01:30 UTC

Attachments (Terms of Use)
lpd log file? (3.44 KB, text/plain)
2003-01-24 20:00 UTC, Need Real Name
no flags Details

Description Need Real Name 2003-01-13 03:38:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3; Linux)

Description of problem:
When I try to print a postscript file using kghostview (on my HP LJ5 using the ljet 4 driver), I get 2 1/4 pages (I have to eject the last page by hand) then lpq stalls.  lpq first shows:

Printer: lp0@dt048n86
 Queue: 1 printable job
 Server: pid 24775 active
 Unspooler: pid 24778 active
 Status: IF filter 'mf_wrapper' filter msg - 'Using NimbusSansL-Regu font for NimbusSanL-Regu.' at 19:22:25.320
 Rank   Owner/ID                  Class Job Files                 Size Time
active anash@dt048n86+772           A   772 /tmp/kde-anash/kgho 326464 19:22:22
done   anash@dt048n86+831           A   831 /tmp/kde-anash/kdep 176697 12:44:39

then: (sometimes) same report but "Stalled" instead of "active."

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Open a postscript file (with 3 pages or more) in kghostview	
2.Attempt to print it

Actual Results:  I got the behavior I described above:  2 1/4 pages, then lpd stalls.
(Sometimes I just get a really long delay (many minutes) after 2/1/4 pages, then printing spontaneously resumes, then pauses again for many minutes after a few more pages).  

Expected Results:  The whole document should have been printed.	

Additional info:

I tried several documents and always got the same behavior.  

This is what I have in /etc/printcap


Comment 1 Tim Waugh 2003-01-20 18:46:06 UTC
Does 'lpr file.ps' show the same behaviour?  I suspect this is a kghostview bug.

Comment 2 Need Real Name 2003-01-20 19:19:26 UTC
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 

Comment 3 Tim Waugh 2003-01-21 10:48:42 UTC
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.

Comment 4 Need Real Name 2003-01-21 19:57:58 UTC
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 
Thanks for your help! 

Comment 5 Tim Waugh 2003-01-23 20:33:25 UTC
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?

Comment 6 Need Real Name 2003-01-24 20:00:07 UTC
Created attachment 89588 [details]
lpd log file?

Here is the file you requested

Comment 7 Need Real Name 2003-01-24 20:03:55 UTC
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 

Comment 8 Tim Waugh 2003-01-24 23:32:02 UTC
Please try this:

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

(all one line)


cat out.prn > /dev/lp0

(as root)

Does that work?

Comment 9 Need Real Name 2003-01-25 01:27:43 UTC
This seems to work fine.  I have just printed a document with 20+ pages. 

Comment 10 Tim Waugh 2003-01-27 15:29:06 UTC
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 >

(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.

Comment 11 Need Real Name 2003-01-27 18:04:00 UTC
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 
cmp out.prn mod.prn reports no differences, so I didn't try printing again. 

Comment 12 Tim Waugh 2003-01-27 18:34:45 UTC
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.

Comment 13 Need Real Name 2003-01-28 18:42:51 UTC
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

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

Comment 14 Need Real Name 2003-02-04 04:53:55 UTC
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. 

Comment 15 Tim Waugh 2003-02-05 17:25:22 UTC
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.

Comment 16 Need Real Name 2003-02-06 00:52:13 UTC
This is what I got (interestingly, printing resumed once I did strace -p 
 9114 ?        S      0:00  \_ lpd (Server) 'lp0' 
 9115 ?        S      0:00      \_ lpd (Worker - Print) 'lp0' 
 9116 ?        S      0:00          \_ /bin/bash 
 9127 ?        S      0:00              \_ /bin/bash 
 9128 ?        S      0:00                  \_ /usr/bin/perl 
 9129 ?        S      0:00                      \_ /usr/bin/perl 
 9130 ?        S      0:07                          \_ /usr/bin/perl 
 9131 ?        S      0:00                          \_ sh -c 
 9132 ?        S      0:00                              \_ sh -c gs '-dBATCH' 
 9134 ?        S      0:01                              |   \_ gs -dBATCH 
 9133 ?        S      0:00                              \_ perl -e while 
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 
 <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) = 
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) = 
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) = 
write(1, "\36\3\370\10>\25\0\33*b9W\37\231\34\37\'\360\37\17\34\33"..., 145) = 
write(1, "\0\6\0\5|\3\37!\1\376*\7\360\3|\33*b54W\37\234\37\t\374"..., 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) = 
write(1, "|\2\370\2?\33*b31W\37\234\177-\1\376\v\374\t\376\231\370"..., 31) = 
write(1, "\3)\3\370\23\177-\1\376\v\374\33*b32W\37\242\300\6\17,"..., 235) = 
write(1, "\17)\17\360\2\360\350\7\377\377\377\377\377\377\376\6\340"..., 24) = 

Comment 17 Tim Waugh 2003-02-06 11:53:05 UTC
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.

Comment 18 Tim Waugh 2005-09-16 16:01:30 UTC
We no longer ship LPRng.

Note You need to log in before you can comment on or make changes to this bug.