Bug 439837 - Sendmail takes a very long time to start
Sendmail takes a very long time to start
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: sendmail (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
: Reopened
: 499820 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-31 13:17 EDT by Orion Poplawski
Modified: 2011-03-06 02:14 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:12:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Do not sleep for 60 seconds for a miracle to happen (1.63 KB, text/plain)
2008-10-04 04:36 EDT, Lubomir Rintel
no flags Details

  None (edit)
Description Orion Poplawski 2008-03-31 13:17:11 EDT
Description of problem:

Fresh rawhide install.  Sendmail takes about 3 minutes to startup.  Using stock
config.  Note that the network is not up at this point because sendmail starts
before NM.  Sendmail still shouldn't take this long though because we might not
be on a network at all.

# cat /var/log/maillog
Mar 31 11:07:44 xenfdev32 sendmail[2276]: My unqualified host name (xenfdev32)
unknown; sleeping for retry
Mar 31 11:08:44 xenfdev32 sendmail[2276]: unable to qualify my own domain name
(xenfdev32) -- using short name
Mar 31 11:08:44 xenfdev32 sendmail[2276]: alias database /etc/aliases rebuilt by
root
Mar 31 11:08:44 xenfdev32 sendmail[2276]: /etc/aliases: 76 aliases, longest 10
bytes, 765 bytes total
Mar 31 11:08:44 xenfdev32 sendmail[2280]: My unqualified host name (xenfdev32)
unknown; sleeping for retry
Mar 31 11:09:44 xenfdev32 sendmail[2280]: unable to qualify my own domain name
(xenfdev32) -- using short name
Mar 31 11:09:44 xenfdev32 sendmail[2284]: starting daemon (8.14.2):
SMTP+queueing@01:00:00
Mar 31 11:09:45 xenfdev32 sm-msp-queue[2292]: My unqualified host name
(xenfdev32) unknown; sleeping for retry
Mar 31 11:10:45 xenfdev32 sm-msp-queue[2292]: unable to qualify my own domain
name (xenfdev32) -- using short name
Mar 31 11:10:45 xenfdev32 sm-msp-queue[2294]: starting daemon (8.14.2):
queueing@01:00:00

# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6
192.168.0.150           xenfdev32

Version-Release number of selected component (if applicable):
sendmail-8.14.2-4.fc9.i386
Comment 1 Thomas Woerner 2008-04-01 04:46:47 EDT
The problem is that xenfdev32 is not a full qualified host name. Why are you
adding this name like this?
Comment 2 Orion Poplawski 2008-04-01 11:14:03 EDT
I'm not.  Anaconda is.  I still don't understand what sendmail is trying to
accomplish by sleeping though.
Comment 3 Thomas Woerner 2008-04-09 09:31:38 EDT
It is trying to get a full qualified domain name (FQDN). Please fix your network
configuration. You could use system-config-network for this.
Comment 4 Orion Poplawski 2008-04-09 12:28:25 EDT
The network configuration is as done by anaconda.  I contend that the machine
should start up fine (quickly) without any user modification.  I've added the
anaconda team to the cc to get their input.  I also contend that sendmail
sleeping serves no purpose - there is almost zero chance that it will be able to
resolve the domain 60 seconds later than the first time it tries.
Comment 5 Bug Zapper 2008-05-14 04:28:49 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Lubomir Rintel 2008-10-03 11:29:19 EDT
This is a major inconviniece and probably the first and most frequent problem new Fedora users hit. Despite sleeping for resolving its name is a major weirdness, it should, at the very least be done in background at all.
Comment 7 Lubomir Rintel 2008-10-04 04:36:45 EDT
Created attachment 319447 [details]
Do not sleep for 60 seconds for a miracle to happen

This fixes the issue.

Thomas; if you're not convinced yet, here's a couple of reasons the current behavior is wrong.

1.) This causes a major pain to substantial amout of users (just google for sendmail's log message, or slow startup trouble), without them even knowing what's going on.

2.) This is not caused by bad configuration by user. Anaconda does not require the host name to be fully qualified, or even resolvable.

3.) This assumes that user has a network configured, which assumes he has a NIC (or a dummy interface, or an alias to loopback in /etc/hosts for his hostname, neither of which is done by anaconda). We use it as a local mailer in default configuration, don't we? Why is this even needed.

4.) The comment in the code says it's a mess. Mess is not good, is it?

5.) Waiting sixty (!) second for a name service to come up and resolve the name is insane, isn't it? Imagine every internet application did this. Would you be happy if firefox blocked all your work for a minute just because it can't resolve something?

6.) At the time sendmail starts we probably don't have network configured anyways, since NetworkManager is not yet started. How big is the chance we'd get the name in 60 seconds?
Comment 8 Thomas Woerner 2008-10-06 04:56:40 EDT
There have also been reports from other projects, that adding an IP address and a short name only is resulting in problems while booting.

The latest anaconda version in rawhide is not adding host entries with short names only anymore. It is either adding a complete host entry with ip address, fqdn and short name or adding the fqdn and short name to the localhost entry. This depends on the resolvability of the short name given at install time.

This is not a sendmail problem. You see it when sendmail starts and there is no network connection e.g. because of the use of NetworkManager.

Please fix your /etc/hosts file to contain complete host entries.

Closing as NOT A BUG.
Comment 9 Lubomir Rintel 2008-10-06 11:38:13 EDT
Reopening, there are still some problems the patch fixes, that are still here. Not serious enough to warrant a blocker though.

(In reply to comment #7)
> 4.) The comment in the code says it's a mess. Mess is not good, is it?
> 
> 5.) Waiting sixty (!) second for a name service to come up and resolve the name
> is insane, isn't it? Imagine every internet application did this. Would you be
> happy if firefox blocked all your work for a minute just because it can't
> resolve something?
> 
> 6.) At the time sendmail starts we probably don't have network configured
> anyways, since NetworkManager is not yet started. How big is the chance we'd
> get the name in 60 seconds?
Comment 10 Daniel Mach 2008-10-29 09:50:17 EDT
I just installed rawhide using F10-beta netinst CD to the virtual machine.
The host name is 'rawhide'.

Setup is default, I haven't changed anything.
I can confirm, that sendmail starts for a very long time.
This is caused by misconfiguration in /etc/hosts.
Problem is probably in how anaconda saves configuration.

/etc/hosts:
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
127.0.0.1 rawhide

should be:
127.0.0.1 localhost.localdomain localhost rawhide
::1 localhost6.localdomain6 localhost6

I'd consider to reassign this to a different component (anaconda?) to get this fixed before F10 comes out.
Comment 11 Thomas Woerner 2008-12-04 08:48:07 EST
This has already been fixed for F10 in anaconda.
Comment 12 Miroslav Lichvar 2009-05-08 11:30:58 EDT
*** Bug 499820 has been marked as a duplicate of this bug. ***
Comment 13 Joachim Frieben 2009-05-08 12:20:42 EDT
(In reply to comment #11)
Issue still present for current "rawhide" and thus F11 final.
Comment 14 Joachim Frieben 2009-05-08 16:01:14 EDT
The original file /etc/hosts as created for a "rawhide" network install performed on 2009-04-30 reads

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

After appending the hostname as specified in line "HOSTNAME=...." of /etc/sysconfig/network to line #1 of /etc/hosts, sendmail starts again without noticeable delay.
Comment 15 Bug Zapper 2009-06-09 19:57:07 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2009-07-14 14:12:27 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 17 Joachim Frieben 2011-03-06 02:14:44 EST
Issue is back after a fresh DVD install of F14 with an active wireless connection during install time. Both updates and updates-testing channels were enabled in order to retrieve packages from updates and updates-testing as of 2011-03-02.
As reported in comment 14, appending the hostname to line 1 of /etc/hosts allows to avoid the 60 sec delay for each of services sendmail and sm-client and to achieve usual boot times.

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