Bug 962038 - sendmail.service and sm-client.service start very long (2min)
sendmail.service and sm-client.service start very long (2min)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: sendmail (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaroslav Škarvada
Fedora Extras Quality Assurance
:
Depends On:
Blocks: WhyWeBootSoSlow
  Show dependency treegraph
 
Reported: 2013-05-11 01:55 EDT by Igor Gnatenko
Modified: 2013-05-15 10:24 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-13 04:59:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Systemctl status from sendmail.service and s-client.service (2.31 KB, text/plain)
2013-05-11 01:55 EDT, Igor Gnatenko
no flags Details

  None (edit)
Description Igor Gnatenko 2013-05-11 01:55:41 EDT
Created attachment 746506 [details]
Systemctl status from sendmail.service and s-client.service

Description of problem:
Very long start sendmail.service and sm-client.service

Version-Release number of selected component (if applicable):
sendmail-8.14.7-1.fc19.x86_64


How reproducible:
Always on boot.

Steps to Reproduce:
1.Nothing
  
Actual results:
graphical.target @2min 43.398s
└─multi-user.target @2min 43.398s
  └─sm-client.service @1min 43.009s +1min 385ms
    └─sendmail.service @42.891s +1min 117ms
      └─network.target @42.287s
        └─wpa_supplicant.service @32.254s +340ms
          └─basic.target @12.591s
            └─sockets.target @12.591s
              └─dbus.socket @12.591s
                └─sysinit.target @12.519s
                  └─sys-fs-fuse-connections.mount @1min 4.872s +3ms
                    └─systemd-modules-load.service @2.943s +826ms
                      └─systemd-readahead-collect.service @2.333s +509ms

Expected results:
sendmail.service and sm-client.service boots faster =)
Comment 1 Igor Gnatenko 2013-05-11 01:57:11 EDT
$ grep '^hosts:' /etc/nsswitch.conf
hosts:      files dns myhostname
Change to
hosts:      files myhostname dns
not fix problem
Comment 2 Igor Gnatenko 2013-05-11 01:57:29 EDT
$ hostnamectl 
   Static hostname: ThinkPad-X230
         Icon name: computer-laptop
           Chassis: laptop
        Machine ID: 398d419afedc4882a5e7ea850f6f9e5b
           Boot ID: d30fb4736ef5441ea7adc7a815615aaa
  Operating System: Fedora 19 (Schrödinger’s Cat)
       CPE OS Name: cpe:/o:fedoraproject:fedora:19
            Kernel: Linux 3.9.0-301.fc19.x86_64
      Architecture: x86_64
Comment 3 Fedora Blocker Bugs Application 2013-05-11 02:08:18 EDT
Proposed as a Blocker for 19-beta by Fedora user ignatenkobrain using the blocker tracking app because:

 2 minutes boot userspace.. this is very bad.
Comment 4 Adam Williamson 2013-05-11 02:14:07 EDT
Can you provide some more details on your system configuration? This clearly is not affecting all installs, or more people would be complaining (and I haven't seen it in any F19 test install I've done so far).
Comment 5 Adam Williamson 2013-05-11 02:14:30 EDT
Specifically, details on the network config might be useful.
Comment 6 Igor Gnatenko 2013-05-11 02:17:50 EDT
(In reply to comment #4)
> Can you provide some more details on your system configuration? This clearly
> is not affecting all installs, or more people would be complaining (and I
> haven't seen it in any F19 test install I've done so far).
I installed F19 from Beta TC3 DVD.
(In reply to comment #5)
> Specifically, details on the network config might be useful.
I use NetworkManager. router use dhcpd.
Comment 7 Adam Williamson 2013-05-11 02:25:31 EDT
OK, so this is to do with the hostname. I can reproduce this issue if I do an install with the hostname 'mint' (actually, that happened entirely coincidentally, funny story). If I do an install with the hostname 'mint.localdomain', this does not happen.

The default hostname for most installs will be localhost.localdomain, so this bug is not likely to be wide in impact, it will only hit people who choose to use an unqualified hostname, which is kinda 'doctor it hurts' territory. So, -1 blocker, and this may not really be a bug at all.
Comment 8 Adam Williamson 2013-05-11 02:26:21 EDT
Note from the OP's logs:

May 11 09:21:55 ThinkPad-X230 sm-msp-queue[1755]: My unqualified host name (ThinkPad-X230) unknown; sleeping for retry
May 11 09:21:55 ThinkPad-X230 systemd[1]: Starting Sendmail Mail Transport Client...
May 11 09:22:55 ThinkPad-X230 sm-msp-queue[1755]: unable to qualify my own domain name (ThinkPad-X230) -- using short name

that's the 1 minute delay. I saw the same thing in my reproducer.
Comment 9 Jóhann B. Guðmundsson 2013-05-11 03:47:51 EDT
The workaround for this should be pretty obvious fix your dns settings and or add your hostname to /etc/hosts 

-1 blocker -1 FE
Comment 10 Igor Gnatenko 2013-05-11 03:49:29 EDT
Thx Adam. I fixed it.
/etc/hostname
- ThinkPad-X230
+ ThinkPad-X230.localdomain
Comment 11 Jóhann B. Guðmundsson 2013-05-11 04:02:56 EDT
ThinkPad-X230 should have been sufficiant...
Comment 12 Jaroslav Škarvada 2013-05-13 04:59:18 EDT
This is caused by network misconfiguration. This behaviour is there for a very long time (at least since F12 when I started maintaining sendmail and probably much much more longer).

Sendmail tries to translate your hostname to IP. In case you do not have correctly set-up your DNS server, you can workaround it by explicitly adding your hostname to /etc/hosts. In case sendmail is unable to translate your hostname to IP, it suppose it is temporal failure of your DNS server, and retries the query several times with some delay between the queries.

I am closing this as NOTABUG because it is expected behaviour. It is probably OK for servers (the sendmail is primary targeted to) but I agree it can cause troubles to mobile users. In case it is real issue there, we could add distro specific patch to workaround this. But I doubt it would get upstreamed.
Comment 13 Adam Williamson 2013-05-13 11:03:53 EDT
Let's face it, the 'sensible thing to do' for mobiles is not to install a frickin' carrier grade MTA. But I don't know if I want to start that fight up again.
Comment 14 Chris Murphy 2013-05-14 20:06:40 EDT
Adding (In reply to comment #7) 
> The default hostname for most installs will be localhost.localdomain, so
> this bug is not likely to be wide in impact,

Who doesn't change this? Now that avahi is enabled by default and actually works, I always change the hostname to a single word like f17s f18s f19q or whatever. And then I can ssh in with:

ssh chris@f19q.local

Just like I do between other self-respecting mDNS/Bonjour platforms.

If I tack on localdomain, as in f19q.localdomain now this doesn't work right at all. I have to type:

ssh chris@f19qlocaldomain

That's wrong.

As for the argument about incorrectly configured DNS servers, I do not manage a DNS server. If /etc/hosts needs to be changed to appease sendmail, then it's either a sendmail specific problem, or a file that hostnamectl set-hostname should update. I don't have to do these silly things on other platforms, I shouldn't have to do them on Fedora to get it's included, enabled by default, services to behave nicely.
Comment 15 Chris Murphy 2013-05-14 20:25:04 EDT
FYI, changing the hostname from f19q to f19q.localdomain causes other problems. This is not the proper solution to the sendmail problem.

Static hostname: f19q
Takes about 20 seconds before I can ssh into the VM, but sendmail takes forever to start. Not graceful.
[root@f19q ~]# systemd-analyze blame
     1min 372ms sendmail.service
     1min 281ms sm-client.service
        12.249s chronyd.service
        11.852s restorecond.service
         9.306s NetworkManager.service
         8.026s NetworkManager-wait-online.service


Static hostname: f19q.localdomain
Takes 1.5 minutes before I can ssh into the VM, but the sendmail.service is now about 2 seconds instead of a minute.

[root@f19q ~]# systemd-analyze blame
        51.688s firewalld.service
        50.696s restorecond.service
        16.989s avahi-daemon.service
        16.023s systemd-logind.service
        11.908s NetworkManager-wait-online.service
Comment 16 Adam Williamson 2013-05-14 20:48:31 EDT
I don't know what you're doing, but I don't see anything like that on a typical 'localhost.localdomain' install, or any of my production systems (all of which are something.localdomain).

And though my desktop's hostname is 'adam.localdomain' and my laptop's hostname is 'laptop.localdomain', avahi works just fine between them: I can 'ping adam.local' or 'ping laptop.local' and there's no problem.

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