On Tue, Mar 22, 2011 at 12:13 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Mar 22, 2011 at 11:25 AM, Seblu <seblu@seblu.net> 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=864fde8a087c0edbc... 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
On Thu, Mar 24, 2011 at 2:44 AM, Seblu <seblu@seblu.net> wrote:
# 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.
Hm, at least we know exactly where the problem is. But, it will not work for long I guess. I guess this is a bluez bug then. It seems that it is not allowed to fail anymore. Have you seen this commit and accompanying bug report: <http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=7bf4b08d0bd35aaef50926e14c5be277df3550e2>? It seems this was a problem for Fedora 14, and that it was fixed in bluez.
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=864fde8a087c0edbc...
Thanks, I hadn't seen that commit. Deprecating --failed is definitely not systemd specific then, good to know.
I see nothing about this in linux-hotplug mailing list. I will ask them.
Yeah, it was not discussed there. You could also try the bluez mailinglist perhaps? Cheers, Tom
On Thu, Mar 24, 2011 at 10:20 AM, Tom Gundersen <teg@jklm.no> wrote:
On Thu, Mar 24, 2011 at 2:44 AM, Seblu <seblu@seblu.net> wrote:
# 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.
Hm, at least we know exactly where the problem is. But, it will not work for long I guess.
I guess this is a bluez bug then. It seems that it is not allowed to fail anymore.
Have you seen this commit and accompanying bug report: <http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=7bf4b08d0bd35aaef50926e14c5be277df3550e2>? It seems this was a problem for Fedora 14, and that it was fixed in bluez.
If i understand correctly, issue was about an udev new behaviour which use "change" event instead of "add" in some way.
Yeah, it was not discussed there. You could also try the bluez mailinglist perhaps?
Tom do you see answer in linux-hotplug mailing list? My understanding: Let initscripts start bluetoothd and not udev (it should not use to manage services). Regards, -- Sébastien Luttringer www.seblu.net
On Sat, Mar 26, 2011 at 7:29 PM, Seblu <seblu@seblu.net> wrote:
Tom do you see answer in linux-hotplug mailing list?
Thanks for the reminder, I thought I was subscribed, but obviously not...
My understanding: Let initscripts start bluetoothd and not udev (it should not use to manage services).
This was not entirely clear to me. I read the advice as: either use systemd (and do not let udev manage the bluetooth daemon), or retrigger the bluetooth add event when dbus has been (re)started. A third solution is, as you say, to let initscripts manage the bluetooth daemon and remove the functionality from the udev rule. I think maybe the third solution is the cleanest one, but in that case it is an upstream (bluez) bug, as the udev rule file is provided unconditionally (AFAIKS). Actually, I wonder whose benefit the udev rule is supposed to be for: systemd (and similar) should manage bluetooth on its own, so should not have the daemon started by udev, and with a traditional sysvinit system will have the problem that we are faced with now. I think it would be worthwhile to ask the bluez developers what they think is the best solution. Cheers, Tom
On Sat, Mar 26, 2011 at 7:29 PM, Seblu <seblu@seblu.net> wrote:
My understanding: Let initscripts start bluetoothd and not udev (it should not use to manage services).
I have been looking a bit more into this (reading the discussions on the bluez mailinglist). From what I can see Sebastien is absolutely right: udev should not manage the bluetooth service, only inistscripts should. In addition to the problem of bluetooth not working on boot, there is also the problem that it is impossible to disable the bluez daemon and the settings in /etc/conf.d/bluetooth are (sometimes) ignored. I tried compiling bluez with --disable-udevrules, and it seems to have the desired effect. Andrea, maybe something to consider for the next release? Cheers, Tom
participants (2)
-
Seblu
-
Tom Gundersen