when startup delays become bugs
Igor Gnatenko
i.gnatenko.brain at gmail.com
Wed May 15 11:58:25 UTC 2013
On Wed, 2013-05-15 at 13:36 +0200, Lennart Poettering wrote:
> 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.
Lennart, good.
I CC'ed for interested bugs.
--
Best Regards,
Igor Gnatenko
More information about the devel
mailing list