when startup delays become bugs

"J├│hann B. Gu├░mundsson" johannbg at gmail.com
Tue May 14 22:09:15 UTC 2013

On 05/14/2013 09:51 PM, Chris Murphy wrote:
> This is not intended to be snarky, but I admit it could sound like it is.  When are long startup times for services considered to be bugs in their own right?
> [root at f19q ~]# systemd-analyze blame
>        1min 444ms sm-client.service
>        1min 310ms sendmail.service
>          18.602s firewalld.service
>           13.882s avahi-daemon.service
>           12.944s NetworkManager-wait-online.service
>           12.715s restorecond.service
>            2.911s abrt-uefioops.service
>            2.792s NetworkManager.service
>            2.634s spice-vdagentd.service
>            2.589s iprinit.service
>            2.583s iprupdate.service
>            2.319s chronyd.service
> 10 seconds for a service seems obscene. 1 minute is so bad it's hilarious, but also really annoying. I feel like filing a bug against anything that takes more than 1/2 second but maybe that's being overly generous (by filing the bug, that is).
> In sendmail's defense, the time is about the same on F18. (It's consistently a bit faster in an F19 VM running on the same F18 system as host.)

Check your /etc/hosts and ensure you have an entry there for you 
hostname and or your hostname exist in your dns

> But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time where the kernel takes 1.9 seconds. Off hand this doesn't seem reasonable, especially sendmail. If the time can't be brought down by a lot, can it ship disabled by default?

The "defaults" we ship and are enable are not useful to anyone neither 
the server community nor the desktop one.

All the abrt services arguably should disabled by default and enabled 
after users have agreed to using it ( opt in not opt out ) .

I did look into optimizing the boot of one of the spins in F16 but never 
ended up putting my findings and POC to practice and make a usable spin 
out of it there most definitely is room on the for better out of the box 
boot experience for our users.


More information about the devel mailing list