> From [EMAIL PROTECTED] Fri Nov 3 14:25:57 2000
> Date: Fri, 3 Nov 2000 21:36:33 +0000 (GMT)
> From: Colin Bruce <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: LPRng: lpq timeouts
>
> Dear All,
>
> I don't know if this is a bug or a feature but it may be of interest.
>
> There are a couple of values in lpd.conf that control timeouts. They
> are: send_job_rw_timeout and send_query_rw_timeout. The one I have been
> experimenting with is send_query_rw_timeout. We have a queue which can
> get quite big (over 3000 jobs). When I do an lpq on it, sometimes I get
> absolutely nothing back. By setting the send_query_rw_timeout value to
> some large number or even zero that problem goes away. All quite reasonable
> I think.
>
> The problem is that the lpq command indirectly spawns an lpd process to
> get the queue information. This process continues running even though the
> lpq process has timed out. The problem is that the queues get pretty big.
> When one of our users does an lpq command, an lpd process is started. After
> a short while the lpq process dies and since there was no output they issue
> the command again. The same thing happens again and again and again (yes we
> do have that sort of user as well). Eventually they do give up and some time
> later all the lpd processes go away.
>
> Now there are two problems with this. The first is more a query really. Since
> the lpd process has broken the connection to the lpq becaues of the timeout
> wouldn't it be better for the lpd to die as well. There is little point in
> it carrying on since it can't send its results anywhere after that.
>
> The second problem is caused by that. I can send the main lpd process a
> SIGHUP signal to get it to reread its config files or I can do it with
> an lpc reread all. However, if a subordinate lpd process has been left
> hanging around because of the scenario described above the SIGHUP signal
> regardless of where it came from causes the main lpd process to die.
>
> Best wishes....
> Colin
Try the latest version of LPRng. It seems to handle up to 5,000 jobs with
pretty good latency. This uses a GDBM databse file for status lookup.
It should be MUCH faster.
There will be a bit of a lag for the first LPQ operation until the database
is initialized, but it should be pretty fast after that.
The next release will be even faster...
Get:
ftp://ftp.astart.com/pub/LPRng/private/ <- get the latest beta.
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.
-----------------------------------------------------------------------------
