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

[Chris Murphy]

On Dec 9, 2013, at 11:47 PM, Andrey Borzenkov <arvidjaar at gmail.com> wrote:

> В 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:
>> 
>> 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 :)

Right, sorry this is Fedora 20, specifically the live install.

> 
>> 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?

The argument being used in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=964172

Is that the dmraid package isn't installed if the user hasn't created a dmraid device at install time; except with live installs which will always have it installed (and enabled) and the user is expected to disable dmraid if they don't use it.

It doesn't work this way for XFS devices, or md devices, or LVM devices. So this is pretty puzzling that by design the user is responsible. Maybe it just makes it easier for dmraid to go away.

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

Sure, that seems to work pretty well. It's fast whether md devices exist or not.


Chris Murphy