#990 closed defect (worksforme)

Twitter fails to update when Jabber reconnecting

Reported by: SynrG Owned by:
Priority: normal Milestone:
Component: BitlBee Version: 3.0.5
Keywords: Cc:
IRC client+version: irssi 0.8.15 Operating System: Linux
OS version/distro: Debian squeeze


During the recent DDoS, my Jabber account was repeatedly reconnecting with messages like:

09:35 <@root> jabber - Logging in: Connecting
09:37 <@root> jabber - Login error: Connection timeout
09:37 <@root> jabber - Logging in: Signing off..
09:37 <@root> jabber - Login error: Short write() to server
09:37 <@root> jabber - Logging in: Reconnecting in 900 seconds..

Also during that time, my Twitter account stopped receiving updates. After the DDoS was over, and I had logged out of Twitter and back in again, then logged into Jabber again, Twitter updates were restored.

To reproduce this problem after the DDoS was over, I had to DROP traffic to with iptables at my firewall to simulate the failure in a way that would cause a soft failure (i.e. reconnection attempts are made). After that rule was in place, I logged into both Jabber and Twitter. The Jabber login attempt failed, and immediately started reconnection attempts. Now, some time elapsed before a tweet arrived on the web, so I don't know exactly when Twitter updates failed in bitlbee, but I confirmed that no further tweets arrived after this point, even though I knew they had arrived on the web. It appears, therefore, that Jabber reconnecting causes Twitter to fail to update.

It was insufficient to simply cancel the Jabber account reconnection retries to make my Twitter account work again. I had to log out of Twitter and back in again before new tweets arrived in bitlbee again.

Thanks to everyone on irc who helped me to identify this problem and patiently answered my questions and helped me set up a reproducible failing case, particularly wilmer and TigerP.

Attachments (0)

Change History (8)

comment:1 Changed at 2012-08-19T13:52:51Z by wilmer

Couldn't reproduce this here, strangely. :-( Will keep it running in case it takes a while..

comment:2 Changed at 2012-08-21T21:50:36Z by SynrG <synrg@…>

On Aug 21, 2012, there was another DDoS directed at During this time I retested, first to see if a single failure to login would reproduce the bug (it did not) and a second test that allowed a single reconnection attempt (it did reproduce the bug). My exact steps for that second test were:

  • restart bitlbee
  • identify (starts connecting 6 accounts)
  • after jabber account login fails (with same "Short write()" error I reported above) allow it retry 5s later
  • after the retry fails, bitlbee reports it will wait 15s
  • immediately log the jabber account out with "account 2 off"
  • watch for tweets on the web (there were at least 2) and compare with the #twitter_bitlbee channel (none of these tweets showed up)

comment:3 Changed at 2012-08-21T21:51:40Z by SynrG <synrg@…>

wilmer, you also asked if I use any plugins. I do not.

comment:4 Changed at 2012-12-29T22:55:06Z by wilmer

In a way the JSON branch will fix this as it uses the streaming API instead of polling.

Unfortunately I've never managed to reproduce this and didn't have time to try harder. :-(

comment:5 in reply to:  4 Changed at 2012-12-30T00:07:57Z by anonymous

Replying to wilmer:

In a way the JSON branch will fix this as it uses the streaming API instead of polling.

Unfortunately I've never managed to reproduce this and didn't have time to try harder. :-(

Interesting. Well, in the meantime I don't recall the last time this happened (but maybe that is due to a decrease in frequency of the conditions that cause it more than anything else).

comment:6 Changed at 2012-12-30T00:09:45Z by wilmer

Resolution: notmyfault
Status: newclosed

Let's just assume it's fixed then. It seemed very much like a problem on's end. Feel free to reopen if this happens again, although I'm not sure what could be done against this other than manually deduping.

comment:7 Changed at 2013-01-06T14:35:29Z by wilmer

Resolution: notmyfault
Status: closedreopened

D'oh. It looks like I confused this bug with another one (#998). I'm glad the problem went away for you. Reopening to fix the resolution.

comment:8 Changed at 2013-01-06T14:35:34Z by wilmer

Resolution: worksforme
Status: reopenedclosed

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.