Date: Thu, 13 Sep 2001 17:59:53 +0200 (CEST) From: "Hartmann, O." <ohartman@klima.physik.uni-mainz.de> To: Christoph Sold <so@i-clue.de> Cc: <freebsd-questions@FreeBSD.ORG> Subject: Re: lpd trouble on FBSD 4.4-RC Message-ID: <20010913175731.K68148-100000@klima.physik.uni-mainz.de> In-Reply-To: <3BA0D732.4040801@i-clue.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 Sep 2001, Christoph Sold wrote: Well, you're right! Printing filter is magicfilter from the ports. This filter system suits all aspects of our need, but it uses several fixing routines on the ps throughput and, as you realized, it blows up everything! But if there is no job, nothing, lpd is still not responsive. :>Hartmann, O. wrote: :> :>>On Thu, 13 Sep 2001, Christoph Sold wrote: :>> :>>All right, while this mail came in, I did already this monitoring and :>>found out something strange. The /var partition is about 2 GB in size. :>>'df' shows me that 900MB are used - but that is impossible! :>> :>Well, it is not. See below. :> :>>I checked with 'du -k' thsi partition and du showed up a usage of only 14 :>>MB - what seems more realistic to me. How to check the partition? where is :>>the memory gone? :>> :>If you're using ghostscript, it is very well possible to have the :>machine crash sending a recursive postscript print job. :> :>>At the moment this machine has the most recent 4.4-RC installed and at this time :>>I started again a make world. Last time 'MAKEDEV' after a mergemaster failed :>>due to a bug in the script (after compilation, kernel install I restarted and :>>tried again MAKEDEV all in /dev but with the same failure to exclude kernel :>><-> device dependencies with MAKEDEV). :>> :>>Indeed, the first problem occured likely due to lack of memory. But I can not :>>realize why the local lpc and lpq commands can not connect to the local lpd. :>> :>When ghostscript produces lots of output, which is fed back to the :>printed, lpc is usually pretty unresponsive. Have a look at top as well :>as fstat for the spool volume to get an idea which process hogs your :>print queue. :> :>HTH :>-Christoph Sold :> :>> :>> :>>:>Hartmann, O. wrote: :>>:> :>>:>>Hello. :>>:>> :>>:>>Well, every year again we have strange troubles with our relatively :>>:>>primitive set up printserver. Printserver is a FBSD 4.4-RC machine, :>>:>>buffering incoming printjobs from other hosts and sending it as a kind :>>:>>of gateway to e HP JetDirect 500X printserver. :>>:>> :>>:>>Sending a huge printjob (about 350 MB) seems to kill or disturb the :>>:>>lpd functions. All smaller jobs are to be printed the normal way. :>>:>>We use no limitations within /etc/printcap or by other quoting :>>:>>systems. :>>:>>A further phenomenon is that I cannot access the lpd via lpc on the :>>:>>printserver itself. lpq -a reports an error about a non accessible :>>:>>server, lpc reports that it also can not access the local lpd. :>>:>>>From remote hosts this seems to be all right, so I think there must :>>:>>be a misconfiguration or a kind of bug on the printserver itself. :>>:>> :>>:>>Does anyone has a tip, a hint? :>>:>> :>>:>Make sure the spool directory has enough room to hold the job. :>>:>Additionally, check if this job gets routed through any filters. If so, :>>:>make sure there is enough room for those jobs, too. :>>:> :>>:>A quick test is constantly monitoring your diskspace closely while :>>:>submitting a really big job. :>> :> :> :> -- MfG O. Hartmann ohartman@klima.physik.uni-mainz.de ---------------------------------------------------------------- IT-Administration des Institutes fuer Physik der Atmosphaere (IPA) ---------------------------------------------------------------- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinenraum) Tel: +496131/3924144 FAX: +496131/3923532 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010913175731.K68148-100000>