does not reconnect after suspend/resume

A closer look at the client reveals that it remains in the "away" state after resume from suspend. Changing manually to "available" forces the client to reconnect sucessfully.

Still have the issue (VERY annoying), can nobody reconstruct or approve?

I am affected too.
~$ uname -a; Linux MD97600 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux

I am affected... no login to msn after standby

to all: is the problem specific to msn?

i have nothing but jabber accounts setup in Empathy..
i still have the problem.
I'm on Natty alpha 64

I'm also affected - Maverick 64-bit using google talk accounts. Quite an annoying bug, actually.

Has affected me since 10.10 (32-bit) using Jabber and is very annoying. Still present in empathy 2.32.1 and telepathy-gabble 0.10.

Only ugly work-around is to re-install empathy, empathy-common and telepathy-gabble from Lucid (2.30.3 and 0.8.12 respectively) and then set them to "hold" using 'dpkg --set-preferences'

It affects me on Natty with Google Talk (haven't tested others).

Can those still affected attach logs for empathy? You can grab them from the help - debug menu.

Thanks!

Status changed to 'Confirmed' because the bug affects multiple users.

On Ubuntu 11.10, after suspend, it doesn't reconnect to IRC networks (gimpnet and freenode) until I disable and re-enable the accounts.

In the attached log it wasn't connecting and I did the thing stated above, so you get the "before" and the "after".
I also obscured my usernames for privacy reasons.

Ubuntu 12.04 Precise, empathy 3.4.2-0ubuntu1. Empathy sometimes connects after resume, sometimes don't. In every case the throbber keeps spinning (which generates more workload for compiz and therefore raise CPU usage by the way). Only way to make the throbber disappear is to go offline and online again.

Experienced in 12.04 with IRC; after resume, claims status is "Available", but does not reconnect. One workaround is to select Edit > Accounts, and turn the account off and back on.

Also reported as: https://bugzilla.gnome.org/show_bug.cgi?id=635618

This might not be specific to empathy: I see the same issue in xchat and weechat. There's something else affecting it, though: from home on the wired net, xchat always reconnects right away when I resume from suspend, but when I'm traveling and using wifi, neither xchat nor weechat will reconnect automatically, and I have to go through all the server tabs running manual reconnects. I haven't been able to figure out what the difference is. Happens in 12.04 but it's been true for some time now, definitely not new with Pangolin.

Happens to me in Ubuntu 12.04 as well. All of the chat accounts appear to be online. I'm connected using wifi, so it could be it's related to this.

Sorry, I meant all of the chat accounts appear to be *offline*. I'm using Empathy for gtalk, msn and "people nearby".

Even after manually clicking the "available" option it won't reconnect. I have to explicitely exit Empathy and start it again to make it reconnect.

I can't believe this still isn't fixed, empathy is unusable on a laptop

Easiest workaround I have found: get in the habit of setting status to Unavailable before suspending, and setting to Available after resuming and getting a network connection.

It's very interesting, I have been using 12.04 with the same exact accounts and configs for the longest time now and it only recently started behaving like the bug again. Wish I could recreate it.

I found a workaround that can be scripted.
There is mc-tool for command line status changes:
use "mc-tool list" to get the id of your im account settings.
then do
mc-tool reconnect <im-account-id>
alternatively you could do:
mc-tool request <im-account-id> offline; mc-tool request <im-account-id> online

I wrote a simple script based on lhotari's suggestion. Just place it in /etc/pm/sleep.d/ , it should reconnect all accounts of all users running empathy. Please note that it sets all statuses to "online", not to their previous states on resume.

https://wiki.ubuntu.com/Releases

The workaround in post #23 works perfectly. Thnx!

This bug seems have the status 'expired'. I still have the problem on Mint 19, which is based on Ubuntu 18.04 LTS. The problem is rather notorious: there is much about it on askubuntu, yet no report of a proper fix); compare also herein #1590985. Who do I turn to?