From owner-freebsd-questions Thu Sep 13 8:56:41 2001 Delivered-To: freebsd-questions@freebsd.org Received: from gekko.ms-agentur.de (server.ms-agentur.de [62.153.134.194]) by hub.freebsd.org (Postfix) with ESMTP id 0E28237B40E for ; Thu, 13 Sep 2001 08:56:37 -0700 (PDT) Received: from i-clue.de (automatix.i-clue.de [192.168.0.112]) by gekko.ms-agentur.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA18897; Thu, 13 Sep 2001 18:05:51 +0200 Message-ID: <3BA0D732.4040801@i-clue.de> Date: Thu, 13 Sep 2001 17:56:34 +0200 From: Christoph Sold User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:0.9.3+) Gecko/20010905 X-Accept-Language: de, en MIME-Version: 1.0 To: "Hartmann, O." Cc: freebsd-questions@FreeBSD.ORG Subject: Re: lpd trouble on FBSD 4.4-RC References: <20010913171806.Q68148-100000@klima.physik.uni-mainz.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message