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

Chris Murphy lists at colorremedies.com
Mon Dec 9 11:42:21 PST 2013


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

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


More information about the systemd-devel mailing list