Bug 57216 - sendmail initscript invocation of make does nothing, databases are not updated
Summary: sendmail initscript invocation of make does nothing, databases are not updated
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sendmail   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Florian La Roche
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-07 01:17 UTC by Need Real Name
Modified: 2007-04-18 16:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-07 20:43:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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.

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:


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.


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
      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

Comment 3 Dale Stimson 2002-08-13 19:12:47 UTC
[Note: I'm the original reporter.  I've retired dale@accentre.com 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
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).

Note You need to log in before you can comment on or make changes to this bug.