Teams Linux app freezes after receiving a chat message when window not focused

Question

[I asked about this on UserVoice forum, but apparently that is no longer active..?]

teams-1.4.00.7556-1.x8664.rpm
Linux distro: Fedora 31
graphical env: xfce
kernel: 5.8.8-100.fc31.x8664

I can send and receive chat messages just fine, as long as I stay focused on the app window, but if I receive a chat message when the app window is not focused, the app appears to freeze for several minutes -- i.e, returning to the app window finds it unresponsive. If I receive a message while in a call (and focused on some other window), the call audio continues normally even though the app freezes. (I don't have a camera, so I can't say what video behavior would be.) When Teams is frozen, there doesn't seem to be any additional CPU usage.

I do not see the problem with the original version I had installed last fall: teams-1.3.00.16851-1, so I've reverted to that. IIRC I also tried downgrading to teams-1.3.00.25560-1 some time ago and saw the issue there too. So I believe it started somewhere between those versions.

BR,
Don

Answer 1

Hi all,

I'm facing the exact same issue since 3 Weeks. Before that I had no problems with Teams.
Manjaro Linux 21.1.0 with KDE 5.22.4. Teams 1.4.00.13653 from AUR Repo. System is up to date.
Did anybody find out the source of this problem? It seems indeed that the Trigger for the freezing UI is when receiving messages.

Best

Answer 2

I am also getting frequent 2 times a day freezes due to Teams:

Aug  8 15:21:00 ubuntu kernel: [519270.313814] GpuWatchdog[2097]: segfault at 0 ip 0000559eb7796006 sp 00007f12539364d0 error 6 in teams[559eb3e00000+5fbe000]

I have disabled GPU acceleration in Teams and have not had any issues so far. I'll keep posting here if I do

Answer 3

A support ticket was opened for this, and in the process of trying various experiments to isolate which combinations of Teams version / Linux distribution / desktop environment produce the issue, I came across a much bigger issue that affects all apps that use dbus/libnotify to send notifications, apparently. Here are just a couple pages on the topic: link1 link2

Note: I've been trying out MATE lately, and that has the same issue I originally saw with xfce.

The core of it seems to be that some desktop environments (DEs) use their own internal notification agents, and some use external ones. The external ones are in some cases auto-started when the session starts and stay running for the duration of the session, but with others (e.g, MATE) the agents are supposed to be started by dbus on-demand, if one is not already running. This is configured by files in /usr/share/dbus-1/services/ which set the org.freedesktop.Notifications service. The problem occurs when more than one DE installs notification service files, as is the situation on my Fedora 31 and 32 machines:

$ ( cd /usr/share/dbus-1/services && fgrep -l org.freedesktop.Notifications *.service | xargs -r grep '^Exec=' )
org.freedesktop.mate.Notifications.service:Exec=/usr/libexec/mate-notification-daemon
org.kde.plasma.Notifications.service:Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications
org.xfce.xfce4-notifyd.Notifications.service:Exec=/usr/lib64/xfce4/notifyd/xfce4-notifyd

dbus accepts the first one it finds, and ignores all subsequent ones, logging these to the system journal:

... dbus-broker-launch[1074]: Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service'
... dbus-broker-launch[1074]: Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share/dbus-1/services/org.freedesktop.mate.Notifications.service'

Then when a notification arrives and there's no handler already running, dbus tries to run the program specified by "Exec" the one file it didn't ignore -- which in my case is the KDE Plasma one. That fails because I'm not running KDE, leading to the hang. (I haven't tried to figure out why it hangs rather than failing immediately.)

BTW, the problem can be easily demonstrated with a single command (Teams not needed), which also hangs:

$ notify-send 'test message'

But if I manually start MATE's notification daemon in the background

$ /usr/libexec/mate-notification-daemon &

and then run notify-send, it works -- and it may unleash a torrent of past notifications that were never delivered. Problem is, for MATE at least, the daemon exits after something like 30 seconds of inactivity.

Sadly, I've not yet found a real solution for this mess. People have suggested some work-arounds, including:

• Remove/Rename the dbus config files you aren't using - but it only "works" if it gets you down to 1, and it's hugely problematic on multi-user machines, or anywhere you want to offer more than one DE (even for yourself), or during the next update (because these files are installed by their respective RPMs). So definitely not an option for me.
• Remove DEs that you aren't using - but that also only "works" if it gets you down to 1 config file, etc. Also not an option for me.
• Add a user-specific config directory -- e.g mkdir -p ~/.local/share/dbus-1/services && ln -sr /usr/share/dbus-1/services/org.freedesktop.mate.Notifications.service ~/.local/share/dbus-1/services/org.freedesktop.Notifications.service -- or anywhere else dbus searches (see dbus-daemon(1) for the complete list). For me, this was successful in eliciting "ignored" messages in the journal for all of the notification service files under /usr/share -- which seemed promising! -- but unfortunately it did not fix the problem.
• Launch your DE's notification deamon manually. For one that won't stay running (like MATE's), you can wrap it in a script that keeps restarting it, but this is lame and there may be small windows of time where notifications are dropped. Seems to me there should be an option to tell the daemon not to exit. Also seems as though that should be the default behaviour, but I may be missing something...

If anyone has come across a better solution, I'd love to hear it.

Bottom line, this does not appear to be an issue that's specific Teams. However, it's interesting that the older version (which I'm still running), 1.3.00.16851, does not have this problem. Perhaps something changed in the way later versions send notifications.

Answer 4

I still got this issue since 3 weeks on version 1.4.00.26453 (64 bits).
I have resinstall teams 3 times : from snap / ubuntu repo or microsoft download page.

Are you going to fix this issue one day or your soft is defintivly broken ?

Answer 5

I had this same issue on i3, turns out it had to do with the notifications not working because I was running on i3. Needed to install dunst and start it in my i3 config with exec --no-startup-id dunst and no longer have this issue.