[systemd-devel] udevadm settle takes too long to finish

[Andrey Borzenkov]

В Mon, 9 Dec 2013 12:42:21 -0700
Chris Murphy <lists at colorremedies.com> пишет:

> 
> On Dec 9, 2013, at 3:33 AM, Thomas Bächler <thomas at 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
> 

There is no such service on openSUSE, which OP has :)

> So why is this enabled by default when there's no dmraid at all, and never has been dmraid metadata on any attached device?
> 

The obvious question is - and how should system know it? Who is
responsible for activating it again after you have added dmraid devices?

Is it possible to trigger dmraid from some udev rule similar to what
mdadm currently does?

> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel