[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