Print jobs coming out on wrong printer

[William R. Knox]

We are having an interesting situation here wherein, on rare occasions,
a print job will come out on a totally different printer than the one to
which it was directed. The question I have is whether or not anyone has
seen anything like this before and, if so, to what they may have tracked
it down.

Our print setup is such that many (in the thousands) Windows 9X/NT users
point their desktops to one of our five Solaris 2.6 print servers via
Samba 2.0.7 (recently upgraded from 2.0.4b, though I understand this
problem predates this, though with less frequency), where it is then
passed off to LPRng 3.6.23 (again, recently updated from 3.6.5, though
again, I understand this problem predates this, though with less
frequency) which will use ifhp 3.3.19 (recently upgraded from 3.3.10 -
see previous upgrade comments). As far as I know, the problem has only
happened so far with our AppSocket printers, though people will put up
with an amazing amount of strangeness in their printing, so I am not
sure. The print command we use in Samba is: 

print command = echo "%L:%p:%U:%m:%T" >> /var/adm/lpd-name-track;
/usr/local/eprint/bin/no_lpr_errors.pl %s; /usr/local/bin/lpr -Z%M
-P%p at localhost -U%U %s; rm -fr %s

where the no_lpr_errors.pl is a PERL script to strip out ^D characters
from straight PostScript (i.e. not PJL) jobs. Our printcap entries for
the AppSocket printers look like this: 

coloa|COLOA:tc=.mailsrv4-ip
coloa|COLOA:client:lpr_bounce:lp=coloa at localhost
coloa|COLOA:server:sh:if=/usr/local/etc/filters/ifhp:of=/usr/local/etc/filters/ofhp:lp=ip.address.of.printer%9100
.mailsrv4-ip:\
        sd=/var/spool/lpd/%P:\
        chooser=/usr/local/eprint/bin/poll_printer.pl:\
        connect_grace=10:\
        network_connect_grace=10

Given the current flaky state of our network, I am almost as likely to
blame this on that, but if anyone else has seen this problem or sees
something in the printcap or print command entry that may cause this
kind of thing, I would love to hear about what you are using, what may
have solved your problem, or any diagnostic work that you may have done
to track it down. Thanks!
-- 
			Bill Knox
			Senior Operating Systems Programmer/Analyst
			The MITRE Corporation