when startup delays become bugs

[Chris Murphy]

On May 14, 2013, at 7:54 PM, Adam Williamson <awilliam at redhat.com> wrote:
> 
> As we've established, sendmail's one minute delay when the hostname is
> not fully qualified looks ugly, but does not actually delay perceived
> startup at all, because neither local nor remote login require
> sendmail.service to be up.

With sendmail enabled, time to ssh success is ~40 seconds.

With 'systemctl mask sendmail', time to ssh success is ~18 seconds. So the sendmail delay does actually delay startup as it relates to remote login.

The fully qualified domain name isn't something I'm compelled to use on other platforms so I don't understand the advantage of it being needed on Fedora. And if I use it, I end up with worse problems in that more services have long delays rather than just sendmail and sm-client, and I can no longer do ssh chris at f19q.local but rather I have to type chris at f19qlocaldomain.

This is the same behavior on F18, with similar delays. It's the same on baremetal, qemu, and virtualbox. And it's the same with two linksys routers, with three different firmware bases tested.

The only two things I change from the stock installation is set the hostname, and 'systemctl enable sshd' and 'systemctl start sshd'. That's it.

> 
> Once you have the list of services with significant start times which
> delay interaction for you, the next step is to investigate why they take
> a long time to start up. It might be inevitable, or the result of a
> local configuration issue that you can change, or it might be a bug. You
> really just need to take a look at the service file, see what it does,
> see if you can figure out specifically what part(s) of that service's
> startup process are slow, and if there's anything that can be done to
> improve it.

Is there a way to get more verbosity, selectively per service, to find what what it's doing or waiting on when it has a significant start time. And what's a significant start time? 2 seconds? 20 seconds?
> 
> Like I said, performance optimization is rarely simple. You're usually
> dealing with a very complex system which inevitably means you need to be
> isolating the places where you can make a practical difference, and
> evaluating whether that's possible.

Well it is relatively easy to just mask sendmail and disable sm-client, especially seeing as I don't need an MTA running. Even if there are good reasons for one being installed by default, I really doubt the majority of Fedora users benefit from it being enabled by default.


Chris Murphy