Bug 57216

Summary: sendmail initscript invocation of make does nothing, databases are not updated
Product: [Retired] Red Hat Linux Reporter: Need Real Name <dale+bz>
Component: sendmailAssignee: Florian La Roche <laroche>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: agreene, ml-bz-dale
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-12-07 20:43:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2001-12-07 01:17:20 UTC
Description of Problem:

Symptom:  Reboot or "service sendmail restart" (i.e., execution
of "/etc/rc.d/init.d/sendmail start") do not update
the indexes for the databases in /etc/mail although it appears
that the intention was to do so.

Diagnosis:
File /etc/rc.d/init.d/sendmail's function "start" attempts to
update the indexes of databases under /etc/mail with command:

    make -C /etc/mail -q

The "make" command has no effect because the "-q" instructs
make to do nothing except issue a special exit status if any
targets are out of date.

I suspect that the "-q" was added in the mistaken belief that
it would simply suppress make's message output (as in "quiet").
To "make", "-q" stands for "question" -- not "quiet".

Suggested solution:  Use "-s" for "silent".
Change the relevant line to be:

    make -C /etc/mail -s

Version-Release number of selected component (if applicable):

Redhat 7.1 with updated sendmail-8.11.6-2.7.1
or Redhat 7.2 with sendmail-8.11.6-3

How Reproducible:

Always

Steps to Reproduce:
1. touch /etc/mail/virtusertable
2. service sendmail restart
3. Observe that virtusertable.db has not been updated:
       ls -lt /etc/mail/virtusertable*
    but should have been.

Comment 1 Florian La Roche 2001-12-07 20:43:14 UTC
*blush* big problem and thanks to your detailed report. This will be
fixed in 8.11.6-5 or newer and I will provide new errata rpms for
older releases.

Thanks,

Florian La Roche


Comment 2 Anthony E. Greene 2002-08-13 11:32:03 UTC
I think the proposed fix is incorrect. The fix rebuilds the db files whether
they need it or not. That was based on the assumption was that the '-q' option
was mistakenly assumed to be the same as '--quiet'. I don't believe that.

I think it was supposed to mean just what says: "return an exit status that is
zero if the specified targets are already up to date, nonzero otherwise." I
believe that the error is in not checking the status.

The following code checks the status and rebuilds only if needed:

    if test -x /usr/bin/make -a -f /etc/mail/Makefile ; then
      make -C /etc/mail -q
      updatedb=$?
      if [ $updatedb -gt 0 ]; then
        for i in virtusertable access domaintable mailertable ; do
          if [ -f /etc/mail/$i ] ; then
            makemap hash /etc/mail/$i < /etc/mail/$i
          fi
        done
      fi
    fi

Comment 3 Dale Stimson 2002-08-13 19:12:47 UTC
[Note: I'm the original reporter.  I've retired dale due to spam.]

> I think the proposed fix is incorrect. The fix rebuilds the db files whether
> they need it or not

Under RH 7.3 (with all errata), the original fix does not rebuild db files
unless they need it.
I just tried it.  Also, from inspection of the makefile

%.db : %
	@makemap hash $@ < $<

it would seem that it does the right thing; that is, invoking makemap only if
the .db is older than the file upon which it depends.

Is it conceivable you are seeing a different problem?
Did this issue arise under the limbo beta or something, in which case
maybe there's something causing this behavior?

Please take another look at this, as the alternate fix you most recently
proposed:
1.  rebuilds all databases, even if only one needs rebuilding
2.  does not rebuild the "possible" databases, as does the Makefile.
    (I don't know how significant this is, but it seems significant to me).