when startup delays become bugs

Igor Gnatenko i.gnatenko.brain at gmail.com
Tue May 14 22:10:29 UTC 2013


On Tue, 2013-05-14 at 15:51 -0600, 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.)
> 
> 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?
> 
> 
> Chris Murphy
See this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=962038
Can you provide from console hostnamectl ?

-- 
Best Regards,
Igor Gnatenko



More information about the devel mailing list