hi,
the load problem doesn't seem to be fixed, I'm running solaris 2.7 and
by using 'truss' I see much activity from the active daemon, mainly:
fstat(9, 0xFFBEE2A8) = 0
fcntl(9, F_GETFL, 0x00000000) = 130
fstat64(9, 0xFFBEE090) = 0
fstat64(9, 0xFFBEE090) = 0
fcntl(9, F_SETFL, 0x00000082) = 0
poll(0xFFBEE190, 1, 0) = 0
time() = 963915185
time() = 963915185
fstat(9, 0xFFBEE2A8) = 0
fcntl(9, F_GETFL, 0x00000000) = 130
fstat64(9, 0xFFBEE090) = 0
fstat64(9, 0xFFBEE090) = 0
fcntl(9, F_SETFL, 0x00000082) = 0
poll(0xFFBEE190, 1, 0) = 0
time() = 963915185
time() = 963915185
fstat(9, 0xFFBEE2A8) = 0
fcntl(9, F_GETFL, 0x00000000) = 130
fstat64(9, 0xFFBEE090) = 0
fstat64(9, 0xFFBEE090) = 0
fcntl(9, F_SETFL, 0x00000082) = 0
poll(0xFFBEE190, 1, 0) = 0
time() = 963915185
time() = 963915185
fstat(9, 0xFFBEE2A8) = 0
fcntl(9, F_GETFL, 0x00000000) = 130
fstat64(9, 0xFFBEE090) = 0
fstat64(9, 0xFFBEE090) = 0
fcntl(9, F_SETFL, 0x00000082) = 0
poll(0xFFBEE190, 1, 0) = 0
time() = 963915185
time() = 963915185
fstat(9, 0xFFBEE2A8) = 0
fcntl(9, F_GETFL, 0x00000000) = 130
fstat64(9, 0xFFBEE090) = 0
fstat64(9, 0xFFBEE090) = 0
fcntl(9, F_SETFL, 0x00000082) = 0
poll(0xFFBEE190, 1, 0) = 0
time() = 963915185
time() = 963915185
fstat(9, 0xFFBEE2A8) = 0
fcntl(9, F_GETFL, 0x00000000) = 130
fstat64(9, 0xFFBEE090) = 0
fstat64(9, 0xFFBEE090) = 0
fcntl(9, F_SETFL, 0x00000082) = 0
poll(0xFFBEE190, 1, 0) = 0
and so on, and so on ...
Another problem with the release is that 'lpc reread' does not seem to
force the daemon to reread printcap entries. The only way to reread the
printcap on my installation is to kill and restart the lpd-daemon by
hand.
regards
Christoph
[EMAIL PROTECTED] schrieb:
>
> If you have been having problems with
> a) Solaris and high load levels
> b) lpc reread killing off your spooler
> c) parallel port IO problems
> (you should also get the latest ifhp release which
> also has fixes for the same problem)
>
> Then please update to this version.
>
> My thanks to all of the folks who sent in the detailed
> problem report information!
>
> 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)
>
> Release LPRng 3.6.21 - Sun Jul 16 16:58:19 PDT 2000
> Clean up some Tru64 system warnings about casts.
> (Supplied by: "Justus J. Addiss" <[EMAIL PROTECTED]>)
> Seemed to have found a solution to the parallel port problem
> by brutally using fstat() to see if we have a device, and if
> so, then unless it is a tty, assuming that it is a write only
> device. This is stupid, and I just KNOW that when somebody
> adds a USB device I will suffer for this. When you have a
> 'write only' file descriptor, you just do a 'write' with timeout.
> No select, nothing. Just a write. This seems to solve the
> problem. Oh yes. You also make sure the file descriptor
> is non-blocking.
> (By: Patrick Powell <[EMAIL PROTECTED]>)
> There is a bizzare problem with doing select for read on some Solaris
> systems with certain patch sets on file descriptors that have
> been set for non-blocking. The select call will actually return
> and indicate that the device can be read... But when you do,
> you get -1, and EUNAVAIL or some similar code indicating no data
> to be read. This is truly bizzare. To ensure that this does
> not happen, you must do a select on a nonblocking file descriptor.
> To add injury to insult, this seems to not be reliably reproducible.
> You really had to be there for this one. I now set all the file
> descriptors into blocking mode and then do select, then put them
> in nonblocking mode to do the write or read.
> The mysterious 'lpc reread' killing lpd was discovered to be caused
> by trying to free an already freed pointer, which was garbage.
> This was related to cleaning up the memory leak problem in 3.6.20.
> Sigh...
> I cannot spell krbros... krb5... or kb5... and thus cannot invoke the
> dog in the configuration script.
> (Happily pointed out by: John Perkins <[EMAIL PROTECTED]>)
>
> -----------------------------------------------------------------------------
> 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.
-----------------------------------------------------------------------------
