From owner-freebsd-current Tue Nov 10 07:03:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02439 for freebsd-current-outgoing; Tue, 10 Nov 1998 07:03:36 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA02433 for ; Tue, 10 Nov 1998 07:03:31 -0800 (PST) (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 RAA14123; Tue, 10 Nov 1998 17:03:05 +0200 (EET) (envelope-from archer@grape.carrier.kiev.ua) Received: (from uucp@localhost) by kozlik.carrier.kiev.ua (8.9.0/8.9.0/8.Who.Cares) with UUCP id RAA19328; Tue, 10 Nov 1998 17:00:57 +0200 (EET) (envelope-from archer@grape.carrier.kiev.ua) Received: (from archer@localhost) by grape.carrier.kiev.ua (8.9.1/8.9.1) id QAA28210; Tue, 10 Nov 1998 16:56:26 +0200 (EET) (envelope-from archer) Date: Tue, 10 Nov 1998 16:56:26 +0200 (EET) From: Alexander Litvin Message-Id: <199811101456.QAA28210@grape.carrier.kiev.ua> To: Greg Lehey Cc: current@FreeBSD.ORG Subject: Re: The infamous dying daemons bug X-Newsgroups: grape.freebsd.current In-Reply-To: <199811092056.PAA22043@lor.watermarkgroup.com> <199811100136.DAA00563@grape.carrier.kiev.ua> <19981110154327.X499@freebie.lemis.com> Organization: Lucky Grape User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19981110154327.X499@freebie.lemis.com> you wrote: GL> On Tuesday, 10 November 1998 at 3:36:28 +0200, Alexander Litvin wrote: >> LC> I went through swap_pager.c today and found a problem that could potentially >> LC> have bad consequences. It's a comparison between page index in the swap pager >> LC> and the size of the vm object, since a shadowed object may have a non-zero >> LC> paging offset with respect to the swap pager, the comparison should have taken >> LC> the offset into account. This piece of code has been there since '95, so >> LC> I can't say if this was responsible for the daemon dying problem. >> >> It is definitely not responsible. At least for this particular problem, >> though it may fix something else ;) >> >> After applying the patch, and artificially exhausting memory, I promptly >> got: >> >> Nov 10 03:15:34 grape /kernel: swap_pager: suggest more swap space: 61 MB >> Nov 10 03:16:26 grape /kernel: pid 310 (sendmail), uid 0: exited on signal 11 >> Nov 10 03:17:26 grape /kernel: pid 311 (sendmail), uid 0: exited on signal 11 >> Nov 10 03:18:25 grape /kernel: pid 313 (sendmail), uid 0: exited on signal 11 >> Nov 10 03:19:25 grape /kernel: pid 353 (sendmail), uid 0: exited on signal 11 >> Nov 10 03:20:26 grape /kernel: pid 394 (sendmail), uid 0: exited on signal 11 GL> Ah, now that's one that I've been getting without exhausting memory. GL> I'm assuming that these dying sendmails are children of the daemon. GL> What happens when you kill -1 the daemon ("accepting connections on GL> port 25 (sendmail)")? In my experience, it *always* dies with a GL> SIGSEGV after these messages have occurred. Well, as I understand, 'swap_pager: suggest more swap space' does not mean that memory is exhausted, but only that it is about to be exhausted. At least, in this case it didn't come to any processes being killed by kernel. You're right -- that sendmails were childs of a daemon (queue runners). I'm not sure about what happens if I send SIGHUP to the daemon. I think it may or may not restart -- it depends. Last time I examined a 'deseased' daemon (it was not sendmail, but a dummy daemon written specially for testing), it appeared that some range of process memory, where code of dynamic library lives, was corrupt (zeroed in that case). I'll try later to kill -1 such daemon. Now I'm in the process of testing Dima's kludge. Until now I was unable to reproduce a problem. Daemons keep living ;) GL> Greg GL> -- GL> See complete headers for address, home page and phone numbers GL> finger grog@lemis.com for PGP public key --- Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message