10. Debugging and Problem Solving

If you are reading this section, then most likely you have had a problem using ifhp with LPRng. Before going any further, please read RFC1179 (BSD or TCP/IP) Job Transfer Printcap Entry, and make sure that your printcap entry has the lpd_bounce flag set. This is the Most Frequently Asked Question and the Most Frequently Provided Answer on the LPRng mailing list.

The following section outlines a method to debug problems with the ifhp filter. It will make use of some diagnostic options that are normally not used in a printcap entry. First, let us start with a typical printcap entry and a problem.

lw4:
  :lp=10.0.0.14%9100
  :sd=/var/spool/lpd/%P
  :ifhp=/usr/local/lib/filters/ifhp

Command:
  lpr -Plw4 -V /etc/motd

LPR output:

sending job 'papowell@h4+223' to lw4@localhost
connecting to 'localhost', attempt 1
connected to 'localhost'
requesting printer lw4@localhost
sending control file 'cfA223h4.private' to lw4@localhost
completed sending 'cfA223h4.private' to lw4@localhost
sending data file 'dfA223h4.private' to lw4@localhost
completed sending 'dfA223h4.private' to lw4@localhost
done job 'papowell@h4+223' transfer to lw4@localhost
Version LPRng-3.6.14

When trying to print to the print queue, the user discovers that no output comes out of the printer. The immediate suspicion is that the filter is not working. You should make sure that the lpr command is actually sending the job to the print queue. You can then use lpq to discover what happened:

# lpq -llll
Printer: lw4@h4  'Hp : Laserwriter'
 Queue: no printable jobs in queue
 Status: subserver pid 27251 starting at 15:34:09.350
 Status: accounting at start at 15:34:09.357
 Status: opening device 'h14.private%9100' at 15:34:09.366
 Status: printing job 'root@h4+223' at 15:34:09.375
 Status: printing data file 'dfA223h4.private', size 3, IF filter 'ifhp' at 15:34:09.376
 Status: IF filter finished at 15:34:35.012
 Status: printing done 'root@h4+223' at 15:34:35.012
 Status: accounting at end at 15:34:35.014
 Status: finished 'root@h4+223', status 'JSUCC' at 15:34:35.014
 Status: subserver pid 27251 exit status 'JSUCC' at 15:34:35.018
 Status: lw4@h4.private: job 'root@h4+223' printed at 15:34:35.020
 Status: job 'root@h4+223' removed at 15:34:35.101
 Filter_status: accounting at start, pagecount 89696, pages 0 at 15:34:13.304
 Filter_status: sending job file at 15:34:13.306
 Filter_status: starting transfer at 15:34:13.306
 Filter_status: initial job type 'text' at 15:34:13.306
 Filter_status: job type 'pcl' at 15:34:13.306
 Filter_status: transferring 3 bytes at 15:34:13.308
 Filter_status: 100 percent done at 15:34:13.308
 Filter_status: finished writing file, cleaning up at 15:34:13.308
 Filter_status: sent job file at 15:34:13.308
 Filter_status: doing cleanup at 15:34:13.308
 Filter_status: getting end using 'pjl job/eoj' at 15:34:13.309
 Filter_status: end of job detected at 15:34:33.219
 Filter_status: getting pagecount using 'pjl info pagecount' at 15:34:33.219
 Filter_status: final pagecount 89697 at 15:34:35.009
 Filter_status: accounting at end, pagecount 89697, pages 1 at 15:34:35.010
 Filter_status: done at 15:34:35.010

As you can see from the lpq output, the Status section shows what lpd is doing, and the Filter_status section shows what ifhp is doing. This is the first line of defence - make sure that the information and errors reported here are for the correct filter.

If this does not help, then we will start with the basic filter tests and work our way back to the print server. First, you will need a couple of test files. If you have a PostScript printer, find a simple PostScript file - the ellipse.ps file is included in the ifhp distribution in the testscripts directory. You will also need a short text file - /etc/motd is usually handy to use.

Create the /tmp/send file with the following contents:

#!/bin/sh
cp /dev/null /tmp/t
/usr/local/libexec/filters/ifhp -Tdev=/tmp/t,trace,debug=1 </etc/motd 2>/tmp/trace

This will create the /tmp/t file, run the ifhp filter, and put the trace and debugging information into the /tmp/trace file. Run this command using:

#!/bin/sh
sh -x /tmp/send

Examine the output in /tmp/trace. It will look like:

ifhp 15:46:14.402 [27307] main: Debug '1'
ifhp 15:46:14.403 [27307] main: dump <NULL>
ifhp 15:46:14.403 [27307] main: Model_id '<NULL>'
ifhp 15:46:14.440 [27307] main: scanning Raw for default, then model '<NULL>'
ifhp 15:46:14.441 [27307] Select_model_info: id 'default', list->count 1940, model->count 0, init 0
ifhp 15:46:14.448 [27307] Dump_line_list: main: Model information - count 156, max 204, list 0x806e000
ifhp 15:46:14.448 [27307]   [ 0]='T=dev=/tmp/g,trace,debug=1'
ifhp 15:46:14.448 [27307]   [ 1]='banner@'
ifhp 15:46:14.448 [27307]   [ 2]='banner_file=/usr/local/libexec/filters/psbanner.ps'
ifhp 15:46:14.448 [27307]   [ 3]='converter='
ifhp 15:46:14.448 [27307]   [ 4]='debug=1'
ifhp 15:46:14.449 [27307]   [ 5]='default_language=text'
ifhp 15:46:14.449 [27307]   [ 6]='dev=/tmp/g'
ifhp 15:46:14.449 [27307]   [ 7]='duplex_select=1'

Most of the information with debug level 1 is simply showing the details of options, command execution, and error status. This will, however, help with the majority of problems.

You can now modify the /tmp/send file to better reflect your printer.

#!/bin/sh
cp /dev/null /tmp/t
# substitute your ifhp options here
ifhp=model=hp4,status@
/usr/local/libexec/filters/ifhp -Tdev=/tmp/t,trace,debug=1,${ifhp} </etc/motd 2>/tmp/trace

If your printer is a network based printer and you are using RFC1179 transfers, then you can use the following lpr command to send the /tmp/t file directly to the printer:

  lpr -Ppr@host /tmp/t
Example: 
  print queue 'raw'

  lpr -Praw@10.1.1.1 /tmp/t

This form of the command causes lpr to send the job directly to the printer. If this works correctly then we know that there is no problem with ifhp formatting the file, and that the problem must be with the lpd print spooler.

If your printer is network based and uses a socket connection, then you can have ifhp connect to the printer by using the dev=host%port connection option. This is only used for testing or when you want to use the AppSocket protocol.

#!/bin/sh
# substitute your ifhp options here
#  this should always work
#ifhp=model=hp4,status@
#  this does status checking, no pagecount
#ifhp=model=hp4,pagecount@
#  this does status checking and pagecount
#ifhp=model=hp4
/usr/local/libexec/filters/ifhp -Tdev=10.1.1.1%9100,trace,debug=1,${ifhp} </etc/motd 2>/tmp/trace

If you have a windowing system, run this command from one window and in another window use the tail -f /tmp/trace command to view status. Most of the time you will discover that the system is failing to print because either the sync, pagecount, or waitidle step of the printing process is not completing correctly. If there is insufficient detail for you to decide the failure mechanism, set debug=3, or even debug=4 and explore what is happening.

If you have a parallel port connected printer on /dev/lptxx, then you can simply use cat /tmp/t /dev/lptxx and see what happens. If this works, then use:

#!/bin/sh
# substitute your ifhp options here
ifhp=model=hp4,status@
/usr/local/libexec/filters/ifhp -Tdev=/dev/lptxxx,trace,debug=1,${ifhp} </etc/motd 2>/tmp/trace

If you have a serial port printer, then you can use a similar method for setting up a connection. You will need to use the undocumented stty option to set the speed and other parameters. These are identical to those used by LPRng, so you should have no problems.

#!/bin/sh
# substitute your ifhp options here
#  this should always work
#ifhp=model=hp4,status@
#  this does status checking, no pagecount
#ifhp=model=hp4,pagecount@
#  this does status checking and pagecount
#ifhp="model=hp4,stty= 9600 -parity crtscts raw"
stty="9600 -parity crtscts raw"
/usr/local/libexec/filters/ifhp -Tdev=/dev/tty00,trace,debug=1,${ifhp},stty=\"${stty}\" </etc/motd 2>/tmp/trace

If all this does not help, then subscribe to the LPRng mailing list and ask for help.