Subject: Printing (closure?)
To: None <firstname.lastname@example.org>
From: Richard Rauch <email@example.com>
Date: 03/07/1999 15:30:50
Discussion seems to have died down, and I think that I've got answers to
the questions that I asked. Some come from offline experiments, some from
the discussion. In sum:
Conclusions: ``lprm'' and ``lpr -r'' do not work for me; ``lprm'', does,
however, work for some people (at least). Multiple print-queues for a
single device appear to be both safe and within the design of our printer
software (kudos to the author(s)). For at least some (one?) of us,
printer-buffers are Bad Things. (Turning them on/off doesn't seem to much
affect performance on my LQ-850, but correct operation is easier to assure
without the buffer.)
1) lprm: This command works for some people, but apparently not for
everyone (myself included). It has nothing to do with multiple
print-queues (I removed one of mine, shut off my printer so that
jobs would definitely queue, queued up a couple of jobs, and
_tried_ to lprm the jobs; no dice).
I have just bugrep'ed it via the Web. (I checked to see if
there any outstanding bugreports with the substring ``lpr'';
none showed up).
2) lpr -r: No one here seems to know if it might be a bug or a feature
to have this not work, but it seems that it does not work for
anyone who's tried it. The GNU/LINUX crowd seems to deprecate
this feature, but no reason is given. It may be a bug that
our lpr does not honor ``-r'', or it may be a case of the man-page
being out of date.
I have just bugrep'ed this via the Web, as well.
3) Tail-ends of print-jobs being munged by subsequent print-jobs: This
seems to be caused by a variation on the following sequence of
events (I would have to walk through the sources to verify exactly,
so it is part guesswork):
Print-job (A) goes to the printer.
Print-job (A) gets the last of its data sent to the printer---
however, because the printer has a buffer, and is physically
slow, it may continue printing (A) for an unspecified period of time.
Print-job (B) is fired up, through GhostScript. GhostScript prepends
some agressive printer-reset commands (at least for lq850), and
lpd sends (B) to printer, along with agressive printer-reset
commands, before (A) is done printing. Result: (A) has the
last bits trashed, and (B) starts printing at the bottom of the
last page of (A), rather than on the top of its own page.
The exact sequence depends on the scenario. However, the above
describes the gist of the problem.
There IS a delay in lpd switching between print-queues (see (4),
below). However, the delay is not sufficient to flush the buffer
on my LQ-850. (The printer has a 6K buffer, and is not that fast.)
An apparent FIX is to disable the printer buffer. This has been
LIGHTLY tested, and seems to be okay. Ideally, there should be a
way to specify a delay after the end of any given job for any
printer-queue. (Or, perhaps there is a way to tone down the
printer-reset string from GhostScript?)
As I recall, dvips of back-to-back files does not seem to cause
a problem, even with the buffer enabled. Since I have it going
through my ``ps'' printer, it should operate the same as other
``ps'' print jobs. So, either my memory is faulty, here, or
else there is more to the story than I see.
4) Multiple printer-queues for single printers work flawlessly, as far as
I can tell.
Although UNIX doesn't generally block multiple writers to files or
devices, BSD does have a cooperative filelocking mechanism, which
may be what lpd is using. In any case, while one print-job is
running, lpd WILL block other queues using the same physical printer.
(This, in any case, works correctly with /dev/lpt0, on i386 1.3.3.)
If one queue is actively using the indicated device, and another
job is trying to run on the same device in another queue, lpc's
``status'' command will report the second logical printer is
down. The condition automatically clears momentarily after the
first job completes. (Exactly how this works, I am not sure.
lpd could be auto-restarting every minute, say; or it may be
using some kind of IPC to indicate availability. The curious
may consult the source code. For the moment, I am content that
it works. If you try this, note especially what I say about
buffers, above---although the buffering problem seems somewhat
independant of multiple queues, I think that it might be exacerbated
Here is an abbreviated version of my /etc/printcap (sans comments):
lp|local line printer:\
...where /usr/local/libexec/printer-filters/ps looks something like:
/usr/pkg/bin/gs -sDEVICE=lq850 -q -sOutputFile=- -
"I probably don't know what I'm talking about." --firstname.lastname@example.org