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.