[1317] in linux-net channel archive
LPR Daemon waits forever.
daemon@ATHENA.MIT.EDU (Peter Maersk-Moller)
Fri Nov 3 14:49:31 1995
Date: Thu, 2 Nov 1995 17:21:50 +0100
From: Peter Maersk-Moller <pm@ghdsign.dk>
To: linux-net@vger.rutgers.edu
Cc: pm@ecad
Hi Linux users!
I have a couple of PC's running Linux 1.2.8 and 1.3.11. They have all been
setup to spool their printer data to a QMS860 PostScript Printer using TCP/IP
and Ethernet.
Normally everything works fine, but a few times a day, the
daemons (lpd) on the linuxboxes stop sending data to the printer. This
happens when I spool a lot more data than the printer can receive. When
I examine the daemons (with ps) I get:
41 ? S 0:00 lpd
5883 ? S 0:00 lpd
So both the parent and it child process still live.
When I look at the net (with netstat -a) I get
tcp 0 0 gert:1005 qms:printer ESTABLISHED
So the connection remains, but nothing gets through. A query on the printer
(with lpq) return
gert: sending to qms
Rank Owner Job Files Total Size
1st bin 539 (standard input) 951377 bytes
2nd bin 540 (standard input) 951377 bytes
3rd bin 541 (standard input) 951377 bytes
4th bin 542 (standard input) 951377 bytes
5th bin 543 (standard input) 951377 bytes
6th bin 544 (standard input) 951377 bytes
Printer Status ---> No Error
no entries
So files remain to be printed, but the child daemon of lpd seems to be waiting
forever. If I kill the lpd daemons and restart the lpd, the files get though
again until next stop.
Does anybody have a clue. I use to let the Linuxboxes send their print data
to a single SUN which spooled the data and send it to the printer when
possible, but the spoolersystem in Solaris is so broken, that a rumour say
that even Sun admit it (of course not official).
Thanks in advance for any response.
Peter Maersk-Moller (maersk@ghdsign.dk or pm@ghdsign.dk)
\|||/
(. .)
-----------------------------ooO-(_)-Ooo---------------------------------
__ _
/ / (_)__ __ ____ __
/ /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a
/____/_/_//_/\___/ /_/\_\ G N U g e n e r a t i o n . . .
-------------------------------------------------------------------------
|| ||
ooO Ooo
