In regard to: RE: LPRng: disconnected df and cf files from print queue,...:
>I ended up resending the df files, since they were postscript to begin with.
>There were 250 jobs and when I resent them one at a time it overwhelmed the
>queue and caused the error. I had to set a wait time between sending to get
>it to work. I read somewhere that this may be caused by not enough file
>descriptors (first it says it cant lock the file, then it cant open it).
>Will opening up the file descriptors work? Or is there some other fix for
>this problem?
Brendan-
We've seen this exact problem with LPRng 3.7.4 (Open_gdbm locking
failures), and as I mentioned in a question I asked earlier this week,
all gdbm-related routines are gone from later versions of LPRng, and
it's not clear (to me) from the CHANGES file when that happened or what
the rationale was for it. I'm not sorry to see them go, I was just
looking for more info on when and why.
We had previously suspected that it might be being caused by running
out of file descriptors, but on our Linux printserver with the 2.4.x
kernel, doing
cat /proc/sys/fs/file-nr
clearly showed that we hadn't even come close to our tuned filedescriptor
limit of 16384.
What I *hadn't* thought of until seeing your post is that we might be
bumping into a per-user file-descriptor limit. I wasn't even certain
Linux had such a concept, but using `ulimit -a' in my shell on the system,
I can see that my personal "open files" limit is 1024. Since the lpd
workers run as non-root, they would be subject to the limit on open files
(i.e. file descriptors).
You should be able to tell if this is the case by using `lsof' to monitor
the # of files your lpd user has open, near times when you get the locking
errors. I'll be trying that on our system tomorrow. If that turns out to
be the problem, it should be possible to increase the number of file
descriptors available just before lpd is started, i.e. in a start/stop
script:
ulimit -n 2048
/usr/local/sbin/lpd
That *should* do the trick. The maximum number of system-wide file
descriptors is queried and set in different ways on different platforms,
so you'll need to consult your OS documentation to figure out what the
right tuneable is to check, if you need to eliminate the system-wide
number of open files. You should be able to tell if it's a system-wide
problem pretty easily, though, as other things you try run will also get
open errors when the system runs out of file descriptors.
Long-term, moving to LPRng 3.8.x, which doesn't have the gdbm-routines,
is probably a better solution. We noticed that an
lpc status all
ran *much* faster on our cluster printing when using the 3.8.15 lpd and
lpc, in comparison to the 3.7.4 lpc and lpd. The only problem is that the
3.8.15 lpd seems to "lose" jobs. We may try 3.8.12, since others have
seemed to have much better luck with that.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
-----------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------
