Hi It seems that when some programs are trying to activate, when plasma is not running, it is due to plasma_waitforname being activated by dbus, which is waiting for something to bind to org.freedesktop.Notifications, ...which under Weston will not happen, unless I run the notifications plasmoid in plasmawindowed Konsole for example, hangs when I press Tab, for the first time, for about a minute, then it becomes responsive. On my Kubuntu system, it looks like kded5 handles it, when Plasma is down, ...at least according to xprop. I could be wrong... ...but this is on my own compiled version that I am seeing this... Thanks
plasma_waitforname being activated is fine. Konsole shouldn't be blocked on anything though. If it is that's a bug in the notification lib. If you can get a backtrace of konsole whilst it is blocked that would be great.
Created attachment 106758 [details] Small trace of konsole hanging I don't have the full symbols, I can recompile with them if you want, but it looks like it waits...
Ugh, yep. Will fix. Thanks
(In reply to David Edmundson from comment #1) > If it is that's a bug in > the notification lib. I don't believe this has anything to do with a library. When the bus is sent StartServiceByName, it will not send a reply until the started process exits or the desired name is registered (I have not confirmed if there are also timeouts involved.) This means that plasma_waitforme will block all programs that call StartServiceByName for org.freedesktop.Notifications for one minute. I have read but not confirmed that the bus will start at most one service for each name. E.g. if there are two service files providing the org.freedesktop.Notifications name, then the bus will only start one of them. If this is so, then the very presence of the org.kde.plasma.Notifications.service file will __PREVENT__ the real org.freedesktop.Notifications service from starting. This means that simply installing plasma on your system will likely break all applications using notifications. That is unless you're also actively using plasma or autostarting a notification service via some other means. If you agree with this analysis then I hope that this problem will be fixed as soon as possible, e.g. by moving the offending service file to a separate, optional package. Thanks in advance
Created attachment 107141 [details] Backtrace from kwrite with debug symbols during hang I am seeing this same issue running KDE apps like kwrite outside of Plasma when no notification service is running. This is with kde-frameworks/knotify-5.36.0 and kwrite-17.04.3. If I start a notification service, like dunst, the hang goes away. I've attached a backtrace of my kwrite with debug symbols during the hang.
David, any progress with comment #3?
Yeah, patch on phabricator... https://phabricator.kde.org/D6963
*** Bug 383439 has been marked as a duplicate of this bug. ***
Git commit 1c97e1d9741fd15962474f47932dd09728dae76b by David Edmundson. Committed on 29/08/2017 at 08:44. Pushed by davidedmundson into branch 'master'. Don't block starting notification service Summary: We don't need to manually start the DBus service. It blocks the calling app, and dbusServiceExists means that we will always end up going the DBus route over a popup anyway, so it won't do anything useful. The service (in the plasma case plasma-wait-for-name) will be started automatically when we actually send the notification. Also fix d-dbusServiceExists being cleared to false when the first service owner exits. Subscribers: #frameworks Tags: #frameworks Differential Revision: https://phabricator.kde.org/D6963 M +11 -17 src/notifybypopup.cpp https://commits.kde.org/knotifications/1c97e1d9741fd15962474f47932dd09728dae76b
(In reply to David Edmundson from comment #9) Thank you very much. This improves the situation a lot, but there's one thing still missing. I use cmst with classic (legacy) systray provided by tint2 and cmst icon appears after a very long delay. Not reproducible with plasma-workspace-5.9.x.
*** Bug 380974 has been marked as a duplicate of this bug. ***