Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Sep 1998 15:58:18 +0930 (CST)
From:      Mark Newton <newton@atdot.dotat.org>
To:        FreeBSD-gnats-submit@FreeBSD.ORG
Subject:   kern/7925: sendmail, inetd barf after a week or so of uptime
Message-ID:  <199809140628.PAA05701@atdot.dotat.org>

next in thread | raw e-mail | index | archive | help

>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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809140628.PAA05701>