From owner-freebsd-current Sat Jul 11 22:48:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA10658 for freebsd-current-outgoing; Sat, 11 Jul 1998 22:48:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from burka.carrier.kiev.ua (root@burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA10648 for ; Sat, 11 Jul 1998 22:48:26 -0700 (PDT) (envelope-from archer@grape.carrier.kiev.ua) Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by burka.carrier.kiev.ua (8.9.0/8.Who.Cares) with ESMTP id IAA02517 for ; Sun, 12 Jul 1998 08:48:18 +0300 (EEST) Received: (from uucp@localhost) by kozlik.carrier.kiev.ua (8.9.0/8.9.0/8.Who.Cares) with UUCP id IAA01509 for current@freebsd.org; Sun, 12 Jul 1998 08:46:13 +0300 (EEST) Received: (from archer@localhost) by grape.carrier.kiev.ua (8.8.8/8.8.8) id IAA07205; Sun, 12 Jul 1998 08:36:31 +0300 (EEST) (envelope-from archer) Date: Sun, 12 Jul 1998 08:36:31 +0300 (EEST) From: Alexander Litvin Message-Id: <199807120536.IAA07205@grape.carrier.kiev.ua> To: current@FreeBSD.ORG Subject: Re: Arrgh ! resubscribing again again again.... X-Newsgroups: grape.freebsd.current In-Reply-To: <199807120149.SAA18536@usr08.primenet.com> Organization: Lucky Grape User-Agent: tin/pre-1.4-980202 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199807120149.SAA18536@usr08.primenet.com> you wrote: >> > This is normal. >> >> Terry, I think I don't understand fully what you have written later, but one >> thing I know: >> >> It is ok, that sendmail dies when it forks when netscape is running, but >> it is all but not ok, when sendmails childs are dying when no netscape >> is running anymore ! TL> Then force NetScape to uncache the objects that it has places int the TL> X server's shared memroy segment. TL> The problem is that objects in the shared memory segment are not reference TL> counted, and Netscape does nto explicitly free them. TL> You could argue that this is an X server bug (ie: the server should TL> reference count the objects, and decrement the reference count when TL> Netscape's connection goes away, removing the object when the reference TL> goes to zero), and you could argue that this is a Netscape bug. TL> Either way, you can "fix" the galloping memory problem by disabling the TL> shared memory extensions so that Netscape can't use them, and then no TL> matter who is really at fault, the memory leak will go away. >> When this case is ok, then the swap/VM algorithms are bad and faulty! TL> There is still a process context claiming ownership of the memory, and TL> it is therefore not being released back to the system. TL> The faulty behaviour lies in pilot error, of one kind or another. >> Any time, when the system was under high load, I have to kill the >> daemons per hand and to restart (or reboot). This can't be ok. TL> You don't *have* to do that. You *could* shutdown your X server and TL> restart it. You simply choose to have your demons die, instead of TL> doing this and/or limiting the amount of VM available to the X server TL> and Netscape, or disabling the X shm extensions. Terry, your explanation is ok. But what X-server should I shutdown? For I don't have any X's. And yesterday I repeated 'make -j64 buildworld', and as always: sendmail childs die with SIGSEGV, cron seems to be in memory, but no cron jobs run. And all that after makeworld has finished, system is _absolutely_ idle. TL> Terry Lambert TL> terry@lambert.org TL> --- TL> Any opinions in this posting are my own and not those of my present TL> or previous employers. TL> To Unsubscribe: send mail to majordomo@FreeBSD.org TL> with "unsubscribe freebsd-current" in the body of the message --- If you have to ask how much it is, you can't afford it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message