On Tue, Mar 22, 2011 at 12:13 PM, Tom Gundersen <teg@xxxxxxx> wrote:
> On Tue, Mar 22, 2011 at 11:25 AM, Seblu <seblu@xxxxxxxxx> wrote:
> Could you try replacing your bluetooth rules with:
>
> # Run helper every time a Bluetooth device appears
> # On remove actions, bluetoothd should go away by itself
> ACTION=="add|change", SUBSYSTEM=="bluetooth",
> RUN{fail_event_on_error}+="/usr/sbin/bluetoothd --udev"
>
> And after booting (so after dbus is running), calling "/sbin/udevadm
> trigger --action=add --type=failed" manually?
That's works. But as you said, it is now removed from upstream.
>
>> But in any case, if we do not modify the initscripts, the call for
>> errors is done too early.
>
> At the moment udevadm trigger --type=failed is called after the file
> system is mounted, but before dbus is started, so this would not help
> with the current problem (I guess that's what you meant?).
exactly.
> I think the correct place to do it is either at the end of rc.multi as
> you say, or maybe just at the end of the dbus script, to not affect
> people not running dbus, and to make it clear why this is done for the
> future?
Doing this at the end of dbus rc.d script will fix this issue but
seems to be less generic than at the end of rc.multi.
Because it will not allow other programs launched in udev rules to
start if a daemon is required.
> On a related note: I noticed that udev upstream recently removed the
> call to udevadm trigger --type=failed from their systemd unit files,
> which would imply that they think this should never be necessary. This
> particular problem would not happen on a systemd machine, but if it
> turns out that we need to call "--type=failed" in this case, then
> maybe there are other cases as well. So maybe it is worth
> investigating why upstream made the change.
Last commit remove option from manpage and add a death condition in
TODO to --type failed. Actually this is probably a bad idea to patch
in this way.
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=864fde8a087c0edbc0ee3aca83f9289fc32cfcee
I see nothing about this in linux-hotplug mailing list. I will ask them.
Thanks a lot for your help Tom!
--
Sébastien Luttringer
www.seblu.net
