when startup delays become bugs
mzerqung at 0pointer.de
Wed May 15 11:36:57 UTC 2013
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
> 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
A service that needs systemd-udev-settle is a broken service! LVM, you
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:
> 233ms abrt-ccpp.service
> 160ms fedora-loadmodules.service
Somebody should file bugs against all packages that still drop something
I see that kvm and bluez do this still. I filed these bugs now:
> 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).
> 78ms iprdump.service
IBM RAID again? Jeez...
> 64ms sendmail.service
> 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
> 54ms abrt-vmcore.service
> 45ms rpcbind.service
> 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 Poettering - Red Hat, Inc.
More information about the devel