Re: udevadm triggers wrong event type for failed events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Aug 14, 2010 at 18:16, Andrey Borzenkov <arvidjaar@xxxxxxx> wrote:
> I was puzzled why my bluetoothd was not started on boot. It turned out
> the following:
>
> - bluetoothd requires D-Bus so attempt to start it early (may be, as
> early as initrd) fails
>
> - event is saved as failed event; but only device path is preserved, no
> information about which event type failed
>
> - later udevadm trigger --type=failed is run; but by default this
> triggers "change" event instead of "add". There is no "change" action
> for bluetooth subsystem (nor do I think it normally emits such event) so
> nothing happens.
>
> This change was introduced relatively recently in
>
> commit 236fae6cf1a619a92174efdf84cd7d91e7d4348d
> Author: Kay Sievers <kay.sievers@xxxxxxxx>
> Date:   Mon Apr 12 17:56:32 2010 +0200
>
>    udevadm: trigger - switch default action from "add" to "change"
>
>
> Now, I could of course just go and add --action=add to udev-post
> initscript. The question is - is it correct to assume that every failed
> event is "add"? Should not event type be preserved for later correct re-
> trigger?

It should match what we do in the initial init scripts, so adding
--action=add seems right. The defaults seems fine, which are always
'change'.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     [X.org]     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux