On Wed, 2013-05-15 at 13:36 +0200, Lennart Poettering wrote: > On Tue, 14.05.13 20:43, Adam Williamson (awilliam@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
