Bug 8794 - Event handler respawns too fast
: Event handler respawns too fast
Status: RESOLVED FIXED
Product: bluetooth-dun
General
: 1.0
: ARM Maemo
: Unspecified normal (vote)
: ---
Assigned To: Philip Langdale
: general
:
:
:
:
  Show dependency tree
 
Reported: 2010-02-02 22:40 UTC by gemi
Modified: 2010-02-07 19:04 UTC (History)
1 user (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description gemi (reporter) 2010-02-02 22:40:58 UTC
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.
Comment 1 Philip Langdale 2010-02-02 23:06:28 UTC
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.
Comment 2 Philip Langdale 2010-02-07 19:04:04 UTC
I tweaked the respawn limits in version 1.1, which is now in extras-devel.
Please try it out