On Dec 9, 2013, at 3:33 AM, Thomas Bächler <tho...@archlinux.org> wrote:
> Am 07.12.2013 22:29, schrieb Robert Milasan: >> From systemd-analyze dump: >> >> Wants: systemd-udevd.service >> WantedBy: lvm2-activation-early.service >> WantedBy: lvm2-activation.service >> Before: lvm2-activation-early.service >> Before: sysinit.target >> After: systemd-udev-trigger.service >> After: systemd-journald.socket >> References: systemd-udevd.service >> References: systemd-udev-trigger.service >> References: sysinit.target >> References: systemd-journald.socket >> ReferencedBy: lvm2-activation-early.service >> ReferencedBy: lvm2-activation.service > > What's the distribution you are using? Using udevadm settle for lvm is a > waste of boot time and isn't even guaranteed to work (ask Lennart, Kay > or Greg K-H for the full speech). It's a hackish workaround for LVM's > inability to activate volumes automatically. I'm finding that plymouth-start.service uses ExecStartPost= to call udevadm settle twice. The actual culprit though is dmraid-activation.service which is enabled by default (why?) and Wants=systemd-udev-settle.service. dmraid.activation.service also has the #2 biggest blame hit: 4.551s dmraid-activation.service So why is this enabled by default when there's no dmraid at all, and never has been dmraid metadata on any attached device? If I systemctl disable dmraid-activation.service both the dmraid-activation.service hit goes away, as does systemd-udev-settle.service. Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
