From owner-freebsd-bugs Sun Sep 13 23:30:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA11574 for freebsd-bugs-outgoing; Sun, 13 Sep 1998 23:30:10 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA11503 for ; Sun, 13 Sep 1998 23:30:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA07540; Sun, 13 Sep 1998 23:30:01 -0700 (PDT) Received: from atdot.dotat.org (atdot.dotat.org [203.23.150.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA11246 for ; Sun, 13 Sep 1998 23:28:34 -0700 (PDT) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.8.8/8.7) id PAA05701; Mon, 14 Sep 1998 15:58:18 +0930 (CST) Message-Id: <199809140628.PAA05701@atdot.dotat.org> Date: Mon, 14 Sep 1998 15:58:18 +0930 (CST) From: Mark Newton Reply-To: newton@atdot.dotat.org To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/7925: sendmail, inetd barf after a week or so of uptime Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 7925 >Category: kern >Synopsis: sendmail, inetd SIGSEGV after forking after "enough" days of uptime >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 13 23:30:01 PDT 1998 >Last-Modified: >Originator: Mark Newton >Organization: >Release: FreeBSD 3.0-980524-SNAP i386 >Environment: Intel P200 64Mbytes RAM aic7880 UltraSCSI Tulip 10Mbit/sec ethernet >Description: After "n" days of uptime long-running daemons which fork often (inetd and sendmail in particular, but sshd has done it once or twice) start to dump core shortly after forking, i.e.: they accept a connection, then the child process immediately dies, shutting down the connection before any data is transferred. Killing and restarting the offending daemon temporarily fixes the problem, although it usually only takes a day or so to recur. Rebooting solves the problem for another week or so. Daemons which fork more often appear to fail more often too (so sendmail failures are more common than inetd failures, for instance). Each crash is accompanied by a message on the console: pid 5358 (sendmail), uid 0: exited on signal 10 Are we dragging bogus pages from memory mapped files into the cache? I might have PR'ed something about this before, but I can't find it in the database so perhaps I'm imagining it. ) >How-To-Repeat: Reboot. Accept moderate amounts of mail. Wait. Can't narrow it down to a particular cause, unfortunately, although it does seem to be more common after running apps which use more memory. Perhaps, however, my perceptions are being colored by my suspicion that we're mapping (dirty?) pages from the page cache where we shouldn't be. >Fix: Reboot weekly :-( >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message