maemo.org Bugzilla – Bug 8794
Event handler respawns too fast
Last modified: 2010-02-07 19:04:04 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 1.06 After breaking the connection on the tethering computer, the "bluetooth-dun" event handler sometimes respawns too fast, with the result that the handler is stopped, and no further connection can be made, since "rfcomm" is not running anymore. In this state, ># status bluetooth-dun returns >bluetooth-dun (stop) waiting while ># start bluetooth-dun results in >bluetooth-dun (start) waiting >bluetooth-dun (stop) starting >bluetooth-dun (stop) starting >bluetooth-dun (stop) starting >start: bluetooth-dun respawning too fast, stopped Only after waiting a minute or so and retrying several times, bluetooth-dun can be started again (manually using "start"). Unfortunately, I cannot reproduce it reliably, although I tried enabling and disabling BT, and connecting and disconnecting in various sequences.
I've seen the symptom before (DUN service no longer running) but never found the cause, so thanks for digging enough to explain it. I'll see what I can do. In the simplest case, maybe a delay will do the trick or I have to add a more explicit check on rfcomm state (I assume what's happening is that the connection at the rfcomm layer isn't closing instantly) Thanks.
I tweaked the respawn limits in version 1.1, which is now in extras-devel. Please try it out