From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 Description of problem: After attempting to print a pdf file with Adobe Acrobar Reader, lpd began to hang after all print jobs. Previously, this had occurred on occasion when trying to print files using ghostview. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.print anything, eg., cat file.txt > lpr 2. 3. Actual Results: lpr hangs, nothing is sent to the printer. Running lprm and/or restarting lpd have no effect. Here is the console output lp 657 0.0 0.3 2584 980 ? S 09:18 0:00 lpd Waiting lp 662 0.0 0.4 2584 1144 ? S 09:18 0:00 lpd (Server) 'hpLaserJet6L' lp 666 0.0 0.4 2600 1184 ? S 09:18 0:00 lpd (Worker - Print) 'hpLaserJet6L' lp 678 0.0 0.3 1996 900 ? S 09:18 0:00 /bin/bash /usr/share/printconf/util/mf_wrapper -Aroot@localhoslp 688 0.0 0.3 1984 892 ? S 09:18 0:00 /bin/bash /usr/share/printconf/util/mf_postscript_wrapper --mflp 689 0.0 0.7 3288 1996 ? S 09:18 0:00 /usr/bin/perl /usr/sbin/lpdomatic --lprng ljet4-62368.foo lp 710 0.0 0.7 3300 1996 ? S 09:18 0:00 /usr/bin/perl /usr/sbin/lpdomatic --lprng ljet4-62368.foo lp 711 0.0 0.7 3296 2008 ? S 09:18 0:00 /usr/bin/perl /usr/sbin/lpdomatic --lprng ljet4-62368.foo lp 715 0.0 0.3 1964 840 ? S 09:18 0:00 sh -c foomatic-gswrapper -q -dBATCH -dSAFER -dNOPAUSE -sDEVICElp 716 0.0 0.3 1964 848 ? S 09:18 0:00 sh -c gs '-dBATCH' '-dSAFER' '-dNOPAUSE' '-sDEVICE=ljet4' '-sOlp 717 0.0 0.4 2600 1144 ? S 09:18 0:00 perl -e while ($line = <>) { my $b = ""; $match |= ( $line =~ lp 718 0.6 3.1 11000 7872 ? S 09:18 0:00 gs -dBATCH -dSAFER -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=/dev/ Expected Results: A normal print job Additional info: /etc/princap hpLaserJet6L:\ :ml=0:\ :mx=0:\ :sd=/var/spool/lpd/hpLaserJet6L:\ :af=/var/spool/lpd/hpLaserJet6L/hpLaserJet6L.acct:\ :sh:\ :lp=/dev/lp0:\ :lpd_bounce=true:\ :if=/usr/share/printconf/util/mf_wrapper: Here is /var/spool/lpd/hpLaserJet6L/log 2002-06-03-15:50:14.214 localhost hpLaserJet6L: Wait_for_pid: IF filter 'mf_wrapper' filter died with signal 'Hangup' 2002-06-03-15:54:38.780 localhost hpLaserJet6L: Wait_for_pid: IF filter 'mf_wrapper' filter died with signal 'Hangup' 2002-06-04-08:27:08.856 localhost hpLaserJet6L: Wait_for_pid: IF filter 'mf_wrapper' filter died with signal 'Hangup' 2002-06-04-09:19:55.459 localhost hpLaserJet6L: Wait_for_pid: IF filter 'mf_wrapper' filter died with signal 'Hangup' All packages are the most recent as of 6/4/02, including foomatic, printconf, ghostscript, and ghostscript fonts
7.2 used LPRng, not lpr. Reassigning.
Does anyone have a workaround available? To twaugh, is there a timetable for resolution of this problem? teds
A workaround was mentioned in other bug reports; here it is: uninstall printconf and printconf-gui, delete the /var/spool/lpd/lp directory, get printtool, rhs-printfilters, and control-panel from the RedHat 6.2 distribution from ftp.redhat.com, and install those. You will then need to add your printers again. start printtool from the command line: printtool& Works fine.
Please reinstall the latest packages, and: 1. Verify that the problem is still there 2. Attach /etc/alchemist/namespace/printconf/local.adl 3. After running 'lpq' after a failed print attempt, attach /var/spool/lpd/<queuename>/lpq.0 Thanks.
Created attachment 73505 [details] log file
Created attachment 73506 [details] log file
You have installed AFPL Ghostscript 7.04. This isn't supported in Red Hat Linux 7.2. If you uninstall that, things will probably work again.
Created attachment 73764 [details] log file
Created attachment 73766 [details] log file
..meaning that it still doesn't work? Are the symptoms still exactly the same? Run this as root: gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=/dev/lp0 \ /usr/share/printconf/tests/testpage.ps Does that work?
No, here is the console output [root@localhost root]# gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=/dev/lp0 /usr/share/printconf/tests/testpage.ps Error: /invalidfileaccess in --.outputpage-- Operand stack: 1 true Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 0 3 %oparray_pop --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1028/1476(ro)(G)-- --dict:0/20(G)-- --dict:84/200(L)-- Current allocation mode is local Last OS error: 16 Current file position is 18052 GNU Ghostscript 6.51: Unrecoverable error, exit code 1
I don't think that you have all of the updates applied. Specifically, what version of printconf do you have?
Here is what rpm says: [root@localhost root]# rpm -qa | grep printconf printconf-gui-0.3.77-1 printconf-0.3.77-1
0.3.77 was never issued as an update for Red Hat Linux 7.2. Please fetch 0.3.61-4.1 (which was), and install that. To install the packages you'll need to use rpm's --oldpackage flag, since you have the Red Hat Linux 7.3 packages installed. Please confirm the versions of ghostscript and foomatic that you have installed, as reported by 'rpm -q'.
I uninstalled everything and installed the suggested versions. The problem persists. Here are the versions: [root@localhost root]# rpm -q foomatic;rpm -q printconf;rpm -q ghostscript;rpm -q LPRng foomatic-1.1-0.20011218.3 printconf-0.3.61-4.1 ghostscript-6.51-16.2 LPRng-3.7.4-28
Okay, please run this as root: GS_FONTPATH=/usr/share/fonts export GS_FONTPATH gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=/dev/lp0 \ /usr/share/printconf/tests/testpage.ps What does that do?
The command hangs-I've waited about 5 minutes so far. Here is the result of 'ps xau': lp 5426 0.0 0.3 2596 772 ? S Aug29 0:00 lpd Waiting root 5508 0.0 25.5 111160 64748 ? S Aug29 0:00 /usr/lib/mozilla/mozilla-bin root 5710 0.0 0.3 1916 888 ? S 10:56 0:00 pppd 115200 -detach :206.20.111.254 crtscts defaultroute -chaproot 5730 0.2 3.5 13944 9080 pts/5 S 10:57 0:00 gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=/droot 5732 0.0 0.3 1944 892 pts/2 S 10:58 0:00 telnet shell.asan.com root 5733 6.2 3.1 17852 8028 ? S 11:01 0:00 kdeinit: konsole -icon konsole -miniicon konsole root 5734 1.3 0.5 2612 1416 pts/1 S 11:01 0:00 /bin/bash
And does 'dmesg' say anything about lp0?
Here is the reply from dmesg [root@localhost root]# dmesg | grep lp0 lp0: using parport0 (polling). lp0: console ready
Okay, please run this as root: GS_FONTPATH=/usr/share/fonts export GS_FONTPATH gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=outfile \ /usr/share/printconf/tests/testpage.ps What does that do?
It writes to the file 'outfile' -rw-r--r-- 1 root root 155674 Sep 2 21:09 outfile [root@localhost root]# file outfile outfile: HP PCL printer data - US letter page size
Now: cat outfile > /dev/lp0
Nothing was printed. Here is what happens: [root@localhost root]# cat outfile > /devlp0 [root@localhost root]# lpq Printer: hpLaserJet6L@localhost Queue: no printable jobs in queue Status: subserver pid 3756 died with signal 'No signal' at 23:59:46.972
> [root@localhost root]# cat outfile > /devlp0 You mis-typed this. See above.
Sorry about that. Typing correctly, it hangs again: [root@localhost root]# cat outfile > /dev/lp0 Here is the console: root 4261 0.0 0.2 1668 524 pts/3 S 09:21 0:00 cat outfile root 4262 9.0 3.2 18448 8204 ? S 09:21 0:00 kdeinit: konsole -icon konsole -miniicon konsole root 4263 1.5 0.5 2588 1392 pts/4 S 09:21 0:00 /bin/bash root 4294 0.0 0.3 2828 896 pts/4 R 09:21 0:00 ps xau [root@localhost root]# lpq Printer: hpLaserJet6L@localhost Queue: no printable jobs in queue Status: subserver pid 3756 died with signal 'No signal' at 23:59:46.972
And what are the last few lines of the output of 'dmesg' this time? What does 'ls /proc/sys/dev/parport' say, and what about 'cat /proc/sys/dev/parport/parport0/autoprobe'?
Here are the results [root@localhost root]# dmesg | grep lp0 lp0: using parport0 (polling). lp0: console ready [root@localhost root]# dmesg | grep parport parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP] parport0: irq 7 detected parport0: cpp_daisy: aa5500ff(08) parport0: assign_addrs: aa5500ff(08) parport0: cpp_daisy: aa5500ff(08) parport0: assign_addrs: aa5500ff(08) parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP] parport0: irq 7 detected parport0: cpp_daisy: aa5500ff(18) parport0: assign_addrs: aa5500ff(18) parport0: cpp_daisy: aa5500ff(08) parport0: assign_addrs: aa5500ff(08) lp0: using parport0 (polling). [root@localhost root]# ls /proc/sys/dev/parport default parport0 This did nothing: [root@localhost root]# cat /proc/sys/dev/parport/parport0/autoprobe
It's some kernel issue anyway.
Which product are you using now, and is this still an issue?