> From [EMAIL PROTECTED] Sun Oct 15 11:19:40 2000 > Date: Sun, 15 Oct 2000 13:17:12 -0400 (EDT) > From: Vincent Fox <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: LPRng: load balancing queues: subqueues not reliable > > I am sure I am doing something moronic, but I am having much > trouble getting load balancing in LPRng 3.6.26 to work correctly. > Actually the load balancing queue itself seems to work just fine. > It's that the subqueues don't seem to work/print. Perhaps I am making > some really basic mistake that someone can point out. > > I have a load balance queue colorA, and three > subqueues associated with it tek350, tek380, optra40. > If I print to colorA all works fine. If I print to any > of the subqueues, it usually puts the job in the queue > but never makes it "active", e.g. > > Server Printer: optra40@q (dest L1@netgear) 'ECS Optra 40' (serving colorA) > Queue: 1 printable job > Server: no server active > Status: job 'vincent@gypsy+253' removed at 12:16:34.229 > Rank Owner/ID Class Job Files Size Time > 1 vincent@gypsy+885 A 885 colorcir.ps 1815 12:51:15 > > If I do an lpc status all: > > q:/var/spool/lpd/tek380# lpc status all > Printer Printing Spooling Jobs Server Subserver Redirect Status/(Debug) > ripley@q enabled enabled 0 none none > jonesy@q enabled enabled 0 none none > bishop@q enabled enabled 0 none none > call@q enabled enabled 0 none none > apone@q enabled enabled 0 none none > colorA@q enabled enabled 0 none tek350,tek380,optra40 > tek380@q enabled enabled 0 none none > tek350@q enabled enabled 0 none none > tek600@q enabled enabled 0 none none > tek2@q enabled enabled 0 none none > cgc-color@q enabled enabled 0 none none > optra40@q enabled enabled 1 none none (2) > ibb-delenn@q enabled enabled 0 none none > > If I do an lpc release all or lpc up all, it will start up > the subserver and print the job. However, the problem persists. > On following prints I have to do the "lpc up all" once again. > I've tried cleaning all the queues, running through checkpc -V > and assorted other ground-zero solutions with no success. > Any ideas what is going on here? I suggest that you get a little more data. First, LPRng has more debugging stuff than a case of banned DDT. You can enable this by doing: lpc debug colorA 4 lpc debug tekc350 4 lpc debug tek380 4 lpc debug optra40 4 This is the overkill value... 2 is not as chatty. Now you fire up a job: echo hi |lpr -PcolorA and you can look in the log files in the spool directory for more tracing information than you will ever want. You can also do the following. Replace your normal filters with: #!/bin/sh # dummy print filter echo $0 "$@" >&2 sleep 30 cat exit 0 And also set: :lp=/dev/null Now you can fling jobs at the queues without wasting paper. I am curious to know what the problem is, because I don't seem to have any problems here... Of course, if you feel brave, you can try the 3.4.1Beta release... ftp://ftp.astart.com/pub/LPRng/private/LPRng-3.4.1..... Patrick ----------------------------------------------------------------------------- YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST The address you post from MUST be your subscription address 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. -----------------------------------------------------------------------------
