I wrote a note to the list about this very problem back on 8/22 (subject
"Print jobs coming out on wrong printer"), and received the reply that
it was most likely someone forgetting to change the default printer on
their Windows desktop. Now, I've seen someone who had a print job come
out of a printer that was buildings away and which they did not have set
up on their Windows box. In addition (and this is the good part), they
had the _banner_ come out of the correct printer. Our print servers are
often fairly busy and are often running concurrent print jobs, but I had
not played around with forcing it to happen. In addition, we will often
have print jobs being forwarded from the print server which received the
job with Samba to the print server which will send the job to the
printer.
To sum up - someone sends a print job to a Solaris 2.6 box running samba
2.0.7, which prints the job with LPRng 3.6.23, and the banner page (if
banner pages are being printed) comes out of the correct printer, but
the job comes out of the wrong printer.
I think there may be a serious issue here. If there needs to be some
experimentation done to solve it, I am more than willing, as my neck is
getting near the block for this (we have reviews coming up, and if
someone's poor review gets printed out on an unexpected printer and not
picked up, someone's going to get cheesed off, to say the least). I will
start to play around to see if I can force problems to happen in the
meantime.
--
Bill Knox
Senior Operating Systems Programmer/Analyst
The MITRE Corporation
[EMAIL PROTECTED] wrote:
>
> > From [EMAIL PROTECTED] Fri Sep 8 14:05:02 2000
> > From: [EMAIL PROTECTED]
> > Date: Fri, 08 Sep 2000 13:10:05 -0000
> > To: [EMAIL PROTECTED]
> > Subject: LPRNGLIST Various problems with 1 major one
> >
[description of problems I'm not seeing deleted]
> >
> >
> > 5. We have a central server accepting spool requests from a
> > number of remote servers. All servers are using the same version of
> > LPRng. The central server runs on Red Hat version 6.2 and the remote
> > machines run a variety of linux and solaris. The remote servers are
> > set up to spool locally before sending the request to the central
> > server.
> >
> > We find that if requests are made on a remote server very close
> > together then sometimes the request will print on the wrong printer.
> > We can force this to happen by putting three lpr requests in a shell
> > script on a remote machine (running under solaris ) and runnig the
> > script. The central server then receives three requests all showing
> > the correct queue ( -Q ) information but with the printer ( -P )
> > information interchanged, causing the requests to be printed on the
> > wrong printer.
>
> I find this VERY strange... Are you saying that the 'lpr' client
> is SENDING jobs with the wrong printer name OR that the 'lpd' client
> is putting them in the wrong queue?
>
> Note: you can modify the LPD code to make a quick 'one line dump' of
> the incoming request - this will give you a REALLY quick and dirty
> way to find out what is going on. You need to do something like:
>
> {
> static fd;
> char msg[512];
> if( fd == 0 ){
> fd = open( "/var/tmp/lpd.log", O_CREAT|O_APPEND, 0600 );
> }
> if( fd > 0 ){
> SNPRINTF(msg,sizeof(msg),"%s '%s'\n", Time_str(0,0),
>stuff_you_want_to_record);
> Write_fd_str(fd, msg);
> }
> }
>
> This is ugly, but very handy when you have problems. Note the Time_str
> to help you figure out what is going on.
>
> >
> > We can stop this by putting 10 second sleeps between the calls in the
> > script. However as the remote machines are becoming loaded we are
> > finding that incorrect printing is happening more often.
> >
> > We have tried to debug this. However the level 5 debug, which seems to
> > be necessary, stops the problem, presumably because of the time taken
> > to write the debug info!!!!!!!!!!! Can you suggest a way forward
> > here as this is now a real problem?
> >
> >
> >
> > This is my first post and I hope I've not inadvertently contravened
> > any etiquette. I have looked at previous posts but could not find any
> > relevent ones.
> >
> >
>
> No problems.
>
> Patrick Powell Astart Technologies,
> [EMAIL PROTECTED] 9475 Chesapeake Drive, Suite D,
> Network and System San Diego, CA 92123
> Consulting 858-874-6543 FAX 858-279-8424
> LPRng - Print Spooler (http://www.astart.com)
>
> -----------------------------------------------------------------------------
> If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
> or lprng-digest-requests) with the word 'help' in the body. For the impatient,
> to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
> with: | example:
> subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
> unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
>
> If you have major problems, send email to [EMAIL PROTECTED] with the word
> LPRNGLIST in the SUBJECT line.
> -----------------------------------------------------------------------------
-----------------------------------------------------------------------------
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
