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 =)
$ grep '^hosts:' /etc/nsswitch.conf hosts: files dns myhostname Change to hosts: files myhostname dns not fix problem
$ 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
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[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.
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. /etc/hostname - ThinkPad-X230 + ThinkPad-X230.localdomain
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: ssh chris 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.
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
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.