If a controller happened to power off due to any hardware error during the discovery-suspended period initiated by pause_discovery() in bluez, the system was possible to get locked in discovery_suspended_by_system state. No more device discovery was possible if that happened.


In user_chrome.log, un-pause discovery failed as

[1424:1424:1111/205822.767326:VERBOSE1:device_event_log_impl.cc(161)] [20:58:22.767] Bluetooth: EVENT: bluetooth_device_bluez.cc:522 Successfully paused discovery           
[1424:1424:1111/205824.633723:VERBOSE1:device_event_log_impl.cc(161)] [20:58:24.633] Bluetooth: EVENT: bluetooth_device_bluez.cc:1129 Failed to un-pause discovery

This was caused by controller reset due to some hardware error which could be seen in btsnoop.log as

> HCI Event: Hardware Error (0x10) plen 1   [hci0] 2018-11-11 20:58:24.553422
    Code: 0x08

Checking the system log (/var/log/messages), it showed that unpause_discovery() happened to fall between the period between the time instatnts that the adapter was disabled and enabled.

2018-11-11T20:58:24.629566+08:00 INFO bluetoothd[3169]: adapter /org/bluez/hci0 has been disabled
2018-11-11T20:58:24.629664+08:00 DEBUG bluetoothd[3169]: src/adapter.c:unpause_discovery() sender :1.17
2018-11-11T20:58:24.660943+08:00 INFO bluetoothd[3169]: adapter /org/bluez/hci0 has been enabled

Although start_discovery() and stop_discovery() requests were received after, they were all blocked by the discovery_suspended_by_system state.
2018-11-11T20:58:29.978290+08:00 DEBUG bluetoothd[3169]: src/adapter.c:start_discovery() sender :1.17
2018-11-11T20:58:30.113944+08:00 DEBUG bluetoothd[3169]: src/adapter.c:stop_discovery() sender :1.17

To provide a more fault-tolerant service by bluez to upper layers, it is desirable to unset the discovery_suspended_by_system state during such an exception.