when startup delays become bugs

[Lennart Poettering]

On Tue, 14.05.13 20:43, Adam Williamson (awilliam at redhat.com) wrote:

Let me take the opportunity to dissect some of this:

> Startup finished in 411ms (kernel) + 745ms (initrd) + 4.704s (userspace)
> = 5.861s
> 
>           2.745s plymouth-quit-wait.service

This one is misleading, as this just makes sure the bootsplash is
terminated when start-up is complete.

>           2.389s NetworkManager-wait-online.service

https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37

>            479ms iprupdate.service
>            385ms iprinit.service

These appear to be untis that are only necessary for IBM RAID. It's
hugely disappointing if this is pulled into all boots. I wonder if we
can find a different logic for this, for example pulling it in from a
udev rules or so. Or by changing anaconda to install this only onb IBM
RAID systemd... Anyone knows what this is about?

Also, I don't see either of these listed in the default preset
file. This really shouldnt be started by default.

>            356ms systemd-udev-settle.service

This is exlusively LVM's fault. There's really no need to ever have that
in the boot unless you run LVM. 

On many machines LVM is the primary reason why things are slow. I can
only recommend everybody to not install on LVM if you can. It's a real
shame that LVM hasn't gotten their things together still, after all
those years. 

A service that needs systemd-udev-settle is a broken service! LVM, you
are broken!

I am hoping for the day LVM gets kicked out of the default install. Oh
btrfs, why are you still not around?

>            297ms ksmtuned.service

I thought the kernel did this without user-interaction these days?

>            236ms spice-vdagentd.service

I don't see why this is on by default. According to this bug report this
should have been pulled in on-demand only:

https://bugzilla.redhat.com/show_bug.cgi?id=876237

>            233ms abrt-ccpp.service

https://bugzilla.redhat.com/show_bug.cgi?id=963184

>            160ms fedora-loadmodules.service

Somebody should file bugs against all packages that still drop something
into /etc/sysconfig/modules/.

I see that kvm and bluez do this still. I filed these bugs now:

https://bugzilla.redhat.com/show_bug.cgi?id=963193
https://bugzilla.redhat.com/show_bug.cgi?id=963198

>            138ms sm-client.service

Oh my, sendmail. What an emabrassement that we still ship this enabled
by default... If we could at least turn it into something that is
activated on-demand. But I gues touching these sources to implement that
would be too awful...

>            112ms iscsi.service

This really sounds like something that should be socket actviated on
demand rather than run by default.

>             97ms sshd.service

Dito. THis is something to start by default only on hosts where a ton of
people log in all the time.


>             80ms isdn.service

In very new systemd 'isdn.service' is not enabled any more in the preset
file, so this is already gone now.

>             79ms systemd-modules-load.service

Ah, cute, on my machine the only reason this is pulled in is
/etc/modules-load.d/spice-vdagentd.conf -- which also pulls in our old
friend uinput (see above).

https://bugzilla.redhat.com/show_bug.cgi?id=963201

>             78ms iprdump.service

IBM RAID again? Jeez...

>             64ms sendmail.service

Urks...

>             56ms systemd-localed.service

Hmm, this one is weird... It should only be loaded when needed, so I am
surprised tjat there's something that needs this during boot-up.

>             54ms ksm.service

I thought the kernel would do this internally these days without
userspace interaction.

>             54ms abrt-vmcore.service

https://bugzilla.redhat.com/show_bug.cgi?id=963184

>             45ms rpcbind.service

https://bugzilla.redhat.com/show_bug.cgi?id=963189

>             33ms dmraid-activation.service

I wonder if we can change this to pull this in only if DMRAID is
actually used... SOunds wrong to spawn this unconditionally...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.