amd64box ~ # /etc/init.d/hidd start hidd | * Starting hidd ... hidd |grep: /etc/bluetooth/input.service: No such file or directory [ !! ] hidd | * ERROR: hidd failed to start amd64box ~ # ls /etc/bluetooth/ audio.conf input.conf main.conf network.conf rfcomm.conf serial.conf Elijah can confirm this issue. No regression for me, so no block.
I don't understand summary quite well, you mean this is not a regression and all versions in the tree are affected? At least with 4.96 I can start it ok: /etc/init.d/hidd restart hidd | * Stopping hidd ... [ ok ] hidd | * Starting hidd ... [ ok ] Even if /etc/bluetooth/input.service doesn't exist, but it doesn't cause the service to fail for me
Looking at the script, seems that it greps in (non existing) /etc/bluetooth/input.service when hidd fails for any reason. As I cannot find the replacement for /etc/bluetooth/input.service (I cannot find any trace of it in sources) maybe that checking for Autostart=true should be dropped from script. The problem is that hidd is exiting with errors for you and I don't know why :(, maybe you could manually grep for Autostart=true in all your /etc/bluetooth...
Attach your /etc/conf.d/hidd
(In reply to comment #1) > I don't understand summary quite well, Sorry, typo with copy-paste > you mean this is not a regression and all versions in the tree are affected? yep
Created attachment 285177 [details] /etc/init.d/hidd (In reply to comment #3) > Attach your /etc/conf.d/hidd
It's init.d file, not conf.d one ;-)
Created attachment 285181 [details] /etc/conf.d/hidd Sorry, but this evening I'm so strange :P
It's the same as mine :( I guess the next would be to check if hidd runs manually and exits with proper code, trying to run it with the same options as used in init.d... :/
Disclaimer: I don't own any bluetooth devices, just parsing git log and *recent* guides. 1. hidd is only installed with old-daemons useflag 2. input.service went away on bluez-utils 3.29->3.30 upgrade (commit named "Convert input service into a plugin") 3. recently bluetooth is autostarted - everything is handled by udev rules (and I mean upstream 97-bluetooth.rules, not the Gentoo specific), that run bluetoothd for udev upon device add/change 4. unless input plugin is explicitly disabled in /etc/bluetooth/main.conf, it's loaded The bottom line: it seems that the optimal fix is the removal of the hidd init script (and very likely also Gentoo specific udev rules - well unless you're planning to revert all what upstream recently did in this regard).
(In reply to comment #9) > Disclaimer: I don't own any bluetooth devices, just parsing git log and > *recent* guides. > > 1. hidd is only installed with old-daemons useflag Yeah, I am also unsure about if we should still provide "old-daemons" stuff :-/ > 2. input.service went away on bluez-utils 3.29->3.30 upgrade (commit named > "Convert input service into a plugin") OK, thanks, then, I guess we should at least drop that grep command in init script. > 3. recently bluetooth is autostarted - everything is handled by udev rules (and > I mean upstream 97-bluetooth.rules, not the Gentoo specific), that run > bluetoothd for udev upon device add/change > 4. unless input plugin is explicitly disabled in /etc/bluetooth/main.conf, it's > loaded > > The bottom line: it seems that the optimal fix is the removal of the hidd init > script (and very likely also Gentoo specific udev rules - well unless you're > planning to revert all what upstream recently did in this regard). Regarding our udev rule, it's still needed to start /etc/init.d/bluetooth service automatically as, otherwise, people will need to manually add it at boot time (if service is not started, bluetooth device will be disabled if computer was started with it connected, like occurs on a lot of laptops with integrated device)
Affected people: hidd is failing to start on your setups for some reason, please try to manually run it and check it exits with "0" status
Well, given 2. and 4., I don't think hidd can work for anybody out of the box, as you need to explicitly disable input plugin - and unless you've found (and read) some old docs, you're unlikely to do it.
*bluez-4.97-r1 (31 Dec 2011) *bluez-4.97 (31 Dec 2011) 31 Dec 2011; Pacho Ramos <pacho@gentoo.org> +files/bluez-4.67-udev.script, -bluez-4.96-r2.ebuild, +bluez-4.97.ebuild, +bluez-4.97-r1.ebuild, +files/rfcomm-conf.d, +files/rfcomm-init.d: Version bump that also includes IMPORTANT changes: - old-daemons were dropped because they are poorly maintained and I am unable to test them. Also have some problems and look to not work at all in default setups (bug #381355 by Agostino Sarubbo and Rafał Mużyło). If you think you still need some of them, please open a new bug report explaining your needs to let us find a replacement or, if none is available, readd only needed old daemons. - 'bluetooth' init.d script has been completely removed as it was only calling "udevadm trigger --subsystem-match=bluetooth --action=add" at startup. This instruction is now called directly by /lib/udev/bluetooth.sh (the one that was previously calling init.d script and causing problems on systemd setups as reported by mgorny and others (bug #396403), this should also solve bug #389531. Due this change, it's possible that you will start to see how your bluetooth device is not properly detected just after booting if not manually running "udevadm trigger --subsystem-match=bluetooth --action=add", if this is your case, please report a bug to readd a bluetooth init.d script for that (even without getting it automatically started by udev to not hurt systemd users). - Because of previous change, 'rfcomm' part of old bluetooth init.d script has been moved to its own script under /etc/init.d and conf.d. - Due bug 392879 (by Otamay) I have rethink the way some plugins were being installed or not to simply always build and install them. This adds no additional dependencies, also simplifies ebuild preventing it from growing forever with a lot of USE flags and, probably the most important one, makes bluez to simply support and work with more devices. Also remove old.
