From fpscha@ns1.via-net-works.net.ar  Wed Sep 20 10:42:24 2000
Return-Path: <fpscha@ns1.via-net-works.net.ar>
Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10])
	by hub.freebsd.org (Postfix) with ESMTP id CE14C37B422
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 20 Sep 2000 10:42:20 -0700 (PDT)
Received: (from fpscha@localhost)
	by ns1.via-net-works.net.ar (8.9.3/8.9.3) id OAA10111;
	Wed, 20 Sep 2000 14:44:21 -0300 (ART)
Message-Id: <200009201744.OAA10111@ns1.via-net-works.net.ar>
Date: Wed, 20 Sep 2000 14:44:21 -0300 (ART)
From: Fernando Schapachnik <fpscha@ns1.via-net-works.net.ar>
Reply-To: fpscha@ns1.via-net-works.net.ar
To: FreeBSD-gnats-submit@freebsd.org
Subject: Blocking issue while regenerating aliases on 4.1-RELEASE
X-Send-Pr-Version: 3.2

>Number:         21424
>Category:       kern
>Synopsis:       Blocking issue while regenerating aliases on 4.1-RELEASE
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 20 10:50:00 PDT 2000
>Closed-Date:    Wed Jan 30 01:20:33 PST 2002
>Last-Modified:  Wed Jan 30 01:20:35 PST 2002
>Originator:     Fernando Schapachnik
>Release:        FreeBSD 4.1-RELEASE i386
>Organization:
VIA NET.WORKS ARGENTINA
>Environment:

SMP 4.1-RELEASE:

CPU: Pentium III/Pentium III Xeon/Celeron (731.02-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x683  Stepping = 3
  Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA
,CMOV,PAT,PSE36,MMX,FXSR,XMM>
real memory  = 536854528 (524272K bytes)

Busy mail server running the stock sendmail system.

>Description:

        First thing I noticed was that newaliases was getting hung.
Further investigation showed the problem was
~majordom/aliases.majordom.db

        Running makemap hash ~majordom/aliases.majordom <
~majordom/aliases.majordom hunged also.

        A fstat showed only sendmail has this file open, and for
reading only.

        A ktrace shows:
 [...]
 87185 makemap  CALL  open(0xbfbff658,0x622,0x1a4)
 87185 makemap  NAMI  "aliases.majordomo.db"
 [a lot of time... sent kill]
 87185 makemap  PSIG  SIGINT SIG_DFL

        aliases.majordom.db ends with 0 bytes. Removing the file
solves the problem.

        Sometimes same thing happens with virtusertable and similar
aliases-related files.

        Today the same happened with access.db. Lsof showed
sendmail 52975 root 7rR VREG 109,196608 0 35980 /etc/mail/access.db

        which means sendmail has the whole file locked for reading.

        Doing a ps -axl shows lockfs state and a sleeping process
(waiting for a lock, I guess). 

>How-To-Repeat:

  Run newaliases during busy hours. 

>Fix:

        Workaround: Remove the .db file and run newaliases/makemap
acordingly.

        To avoing concurrency problems, I'm using this script:

#!/bin/sh
dir=/usr/local/sendmail_aliases

# Copy actual alias file to fake dir.
cp /usr/local/majordomo/aliases.majordomo $dir/usr/local/majordomo/aliases.ma
jordomo
cp /etc/mail/alias-de-clientes $dir/etc/mail/alias-de-clientes
cp /etc/mail/aliases $dir/etc/mail/aliases
cp /etc/mail/usertable $dir/etc/mail/usertable

# Regenerate aliases inside the cage.
/usr/sbin/chroot $dir /usr/sbin/sendmail -bi
/usr/sbin/chroot $dir /usr/sbin/makemap hash /etc/mail/usertable < /etc/mail/
usertable

# Put aliases files in its proper place.
cp $dir/usr/local/majordomo/aliases.majordomo.db /usr/local/majordomo/aliases
.majordomo.db  
cp $dir/etc/mail/alias-de-clientes.db /etc/mail/alias-de-clientes.db
cp $dir/etc/mail/aliases.db /etc/mail/aliases.db
cp $dir/etc/mail/usertable.db /etc/mail/usertable.db

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sun Aug 26 03:52:20 PDT 2001 
State-Changed-Why:  

Does this problem still occur with newer releases? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21424 
State-Changed-From-To: feedback->closed 
State-Changed-By: sheldonh 
State-Changed-When: Wed Jan 30 01:20:33 PST 2002 
State-Changed-Why:  
Automatic feedback timeout.  This PR remained unchanged in the feedback 
state for more than 4 months. 

If additional feedback that warrants the re-opening of this PR is 
available but not included in the audit trail, please include the 
feedback in a reply to this message (preserving the Subject line) and 
ask that the PR be re-opened. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21424 
>Unformatted:
