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