>Number:         20337
>Category:       kern
>Synopsis:       current-20030213 kernel lets sendmail-current+bells loop
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 14 00:51:01 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Frank Kardel
>Release:        NetBSD 1.6N-20030213
>Organization:
	
>Environment:
	
	
System: NetBSD pip 1.6N NetBSD 1.6N (PIP) #0: Tue Feb 11 13:36:20 MET 2003 kardel@pip:/src/NetBSD/netbsd/sys/arch/i386/compile/PIP i386
Architecture: i386
Machine: i386
>Description:
	The current version of the kernel drives sendmail into a
	tight loop after delivering the mail locally but before 
	removing the mail from the queue. sendmail loops tighly
	on a read(2) that returns EAGAIN over and over again 8-).
	kernels from 2003-02-11 do not show that behavior.
	The sendmail is from pkgsrc/mail/sendmail with some bells
	and whistles added (for TLS/LDAP etc...) thus the sendmail
	i/o code might be more susceptible to changed/unexpected return
	codes from read(2) - older kernels do not trigger that behaviour.
>How-To-Repeat:
	run a 2003-02-13 kernel and deliver mail via sendmail locally.
	The mail will be in the mailbox. mail.local is in zombie state
	(not waited for yet) sendmail 8.12.6 (with many bells and whistles
	compiled) loops on a read(2) returning EAGAIN.
	Killing sendmail leads to another delivery of the mail and another
	looping sendmail (because of the q-run).
>Fix:
	Maybe check kern/sys_pipe.c for glitches - that seems to be the
	only relevant change in the kernel during that time (2003-02-11 - 2003-02-13).
>Release-Note:
>Audit-Trail:
>Unformatted: