Red Hat Bugzilla – Bug 962038
sendmail.service and sm-client.service start very long (2min)
Last modified: 2013-05-15 10:24:45 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):
Always on boot.
Steps to Reproduce:
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
└─wpa_supplicant.service @32.254s +340ms
└─sys-fs-fuse-connections.mount @1min 4.872s +3ms
└─systemd-modules-load.service @2.943s +826ms
└─systemd-readahead-collect.service @2.333s +509ms
sendmail.service and sm-client.service boots faster =)
$ grep '^hosts:' /etc/nsswitch.conf
hosts: files dns myhostname
hosts: files myhostname dns
not fix problem
Static hostname: ThinkPad-X230
Icon name: computer-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
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.
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).
Specifically, details on the network config might be useful.
(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.
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.
Note from the OP's logs:
May 11 09:21:55 ThinkPad-X230 sm-msp-queue: My unqualified host name (ThinkPad-X230) unknown; sleeping for retry
May 11 09:21:55 ThinkPad-X230 systemd: Starting Sendmail Mail Transport Client...
May 11 09:22:55 ThinkPad-X230 sm-msp-queue: 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.
The workaround for this should be pretty obvious fix your dns settings and or add your hostname to /etc/hosts
-1 blocker -1 FE
Thx Adam. I fixed it.
ThinkPad-X230 should have been sufficiant...
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.
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.
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:
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:
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.
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
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
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.