auto-start m-n-d with session

[raveit65]

This is a proof-of-concept rework of an very old PR from 2013. https://github.com/mate-desktop/mate-notification-daemon/pull/10 It removes dbus-activation for notification-daemon and the daemon will start via autostart folder in x11 and wayland session.

Relying on D-Bus activation to launch org.freedesktop.Notifications can result in a race condition if multiple daemons are present on one computer, as explained further in the commit messages.

For example, GNOME 2.x vs KDE: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584859 https://bugs.kde.org/show_bug.cgi?id=212656

And KDE vs. Unity (notify-osd): http://ubuntuforums.org/showthread.php?t=1973315

These are just examples. The general problem is discussed further here: https://bugzilla.redhat.com/show_bug.cgi?id=484945

We have several reports about conflict with kde-notification when both enviroments are installed. This PR should fix the issues.

I like to test this for myself a while because i am not sure about the consequences. In wayfire session the daemon can be started via autostart-command in wayfire.ini.

[raveit65]

[cwendling]

Disclaimer: I have never experienced the problem, so take this with a grain of salt.

Should we really not have the service file? It seems like an expectation many have, and in "most" cases of a system well installed, it should work fine. Can't we instead keep the D-Bus activation, but auto-start the daemon manually? I would expect D-Bus activation not to happen if the name is already claimed. In any case it kind of defeats the purpose of on-demand activation, but if it's a real issue and there isn't a better solution (like advertising environments where the daemon should be preferred), having it running seems a reasonable compromise.

[raveit65]

Personal, i never run in this issue because kde isn't installed. When KDE with their notification-daemon is installed than dbus-activation will use the kde-daemon. Is is easy to test with installing kde :) The problem is just simple, K is before M in the alphabet and both daemons are implementation of the freedesktop-notification-daemon. From Mate view there isn't a problem with xfce-notify-daemon because X is a t the end of the alphabet. This work is exactly what gnome did before they moved notification to the shell.

But starting the daemon via autostart plus using dbus-activation doesn't make any sense. It is just a double functionality. I mean why the daemon should be activated via dbus when the daemon is always running?

Well as i said before this is a proof-of-concept which i want to test for myself. And i do not have a strong intention to get this merged, if all of you prefer dbus-activation. But i think second commit might be the better solution for wayland-only in https://github.com/mate-desktop/mate-notification-daemon/pull/213, ihmo.

[raveit65]

I would expect D-Bus activation not to happen if the name is already claimed.

This is the question......

[cwendling]

But starting the daemon via autostart plus using dbus-activation doesn't make any sense. It is just a double functionality. I mean why the daemon should be activated via dbus when the daemon is always running?

My concern is basically if some people rely on MND as their org.freedesktop.Notification implementation outside of MATE (or even any otherwise XDG-compliant desktop), in which case the change here would break their setup. We could however accept that they have to start the daemon, but it's a change we might want to consider.

I would expect D-Bus activation not to happen if the name is already claimed.

This is the question......

It can be tested just the same: if it happens anyway, sending a notification on a setup showing the bug should try to start the KDE implementation even with this change. So I would think that either this works and we don't have to remove D-Bus activation, or it doesn't help so much (well, the name being claimed would make the KDE implementation to fail registering, unless it tries to override).

[raveit65]

@cwendling I tested installing kde plasma beside Mate in a VM. Notifications in Mate session are complete broken when /usr/share/dbus-1/services/org.kde.plasma.Notifications.service still exists. When i rename the daemon to org.kde.plasma.Notifications.service.save than mate-notification-daemon works again. So the issue is really easy to reproduce. Please try again for yourself if you think that isn't a problem. And as fedora distro maintainer i know there is more than 1 user who have both desktops installed ;) Because all those bugzilla bugreports in the last 10 years were send to me.

Of course can i do another PR with auto-starting the daemon and dbus-activation, but for me it's a double functionality and not needed when the daemon is running. And you never explained why dbus-activation is serious needed for you. But first test for yourself.....

Edit: This wiki describes the problems when several implementation of freedesktop-notification services are installed. https://wiki.archlinux.org/title/Desktop_notifications

[raveit65]

I forgot to say this PR solves the issue in my test VM when /usr/share/dbus-1/services/org.kde.plasma.Notifications.service exists ;)

[raveit65]

I banged my head and found a valid reason for myself to keep dbus-activation. For example when the daemon is killed by a faulty notification application the debus-activation can restart the daemon. Of course this doesn't work when /usr/share/dbus-1/services/org.kde.plasma.Notifications.service exists on the system. Here the daemon needs to restart by hand. I hope now everybody is happy. Please review again.

[raveit65]

Bug list which can be closed with this PR: https://github.com/mate-desktop/mate-notification-daemon/issues/174 https://github.com/mate-desktop/mate-notification-daemon/issues/133 https://github.com/mate-desktop/mate-notification-daemon/issues/115

[yselkowitz]

The D-Bus service file MUST be removed as part of this, otherwise you're not actually fixing the problem.

[cwendling]

What about making the idle exit conditional instead? I've done that there: https://github.com/mate-desktop/mate-notification-daemon/commits/start-with-session The idea is that when D-Bus-activated, it exits on idle like before, but not when started manually or with the session.

[cwendling]

I still think it's less intrusive and less likely to break anybody's working setup if we keep D-Bus activation, but if causes too much trouble I don't care -- so long as a regular MATE session works, that's fine with me in the end.

[cwendling]

The D-Bus service file MUST be removed as part of this, otherwise you're not actually fixing the problem.

Well, it still fixes the problem MATE user sees. But maybe we're not good citizen if we keep it -- yet, AFAICT only GNOME doesn't provide it for its notification implementation (?).

[raveit65]

Before the last update i tried to use X-MATE-AutoRestart=true in desktop file. Same like caja or mate-panel or m-s-d. But for this m-n.d needs to get a session-management-ID which needs a implementation from libsm. This is far away from my current skills :)

[raveit65]

The D-Bus service file MUST be removed as part of this, otherwise you're not actually fixing the problem.

Well, it still fixes the problem MATE user sees. But maybe we're not good citizen if we keep it -- yet, AFAICT only GNOME doesn't provide it for its notification implementation (?).

See link to archwiki.

[raveit65]

I still think it's less intrusive and less likely to break anybody's working setup if we keep D-Bus activation, but if causes too much trouble I don't care -- so long as a regular MATE session works, that's fine with me in the end.

I am fine with dbus-activation because it can restart the daemon. As fedora maintainer i saw a lot of bugs with faulty notifications from application which can kill the daemon.

[cwendling]

I am fine with dbus-activation because it can restart the daemon. As fedora maintainer i saw a lot of bugs with faulty notifications from application which can kill the daemon.

I suggest you give my linked branch a try then. WFM nicely, with the idle exit feature when launched on-demand, and staying forever otherwise.

[raveit65]

The D-Bus service file MUST be removed as part of this, otherwise you're not actually fixing the problem.

I did it first, but other maintainer wasn't happy with it. But i can restore it....if all agree. And current state fixes a lot of problems from Mate point of view.

[cwendling]

Well, it still fixes the problem MATE user sees. But maybe we're not good citizen if we keep it -- yet, AFAICT only GNOME doesn't provide it for its notification implementation (?).

See link to archwiki.

OK, this suggests that actually KDE shouldn't have a problem here, as its daemon is always running? It also shows a solution to select which daemon is activated with D-Bus activation. So it's still gonna be a problem (or a feature) when coupled with other standalone implementations, but would fix MATE, and not impact the other ones (?).

[raveit65]

Well, it still fixes the problem MATE user sees. But maybe we're not good citizen if we keep it -- yet, AFAICT only GNOME doesn't provide it for its notification implementation (?).

See link to archwiki.

OK, this suggests that actually KDE shouldn't have a problem here, as its daemon is always running? It also shows a solution to select which daemon is activated with D-Bus activation. So it's still gonna be a problem (or a feature) when coupled with other standalone implementations, but would fix MATE, and not impact the other ones (?).

I tested current state in VM when kde-daemon is installed. Mnd works fine. In kde session (f38) knotify runs well because k is before M in alphabet. This is how dbus-activation works. If a daemon name starts with A then this daemon will be used

[yselkowitz]

This can still cause conflicts even in DEs with built-in implementations (GNOME and KDE), as it introduces the opening for a race condition during DE startup. The ONLY safe way for multiple services providing the same service name to coexist is for none of them to use service activation and for each to be directly started by its respective DE.

[raveit65]

kde plasma 5 (f38) use dbus-activation too.

[raveit65]

What about making the idle exit conditional instead? I've done that there: https://github.com/mate-desktop/mate-notification-daemon/pull/new/start-with-session The idea is that when D-Bus-activated, it exits on idle like before, but not when started manually or with the session.

You linked a non existing PR :)

[cwendling]

@raveit65 oops, I meant to link to the branch… see commit there: https://github.com/mate-desktop/mate-notification-daemon/commits/start-with-session. Anyway, it's easy enough to test locally:

$ git fetch origin start-with-session
$ git checkout --track origin/start-with-session
$ make

[raveit65]

@cwendling I didn't call for help, i know to fetch a branch. I only wanted to blame you :P I tested your branch. It seems to work in x11 mate-session but it doesn't work in wayland session, which was my first intention for all this work. Here the daemon crashes when i use notify-send command. First terminal:

[sb-wayland@mother ~]$ /usr/libexec/mate-notification-daemon

** (mate-notification-daemon:228742): WARNING **: 17:44:23.295: Failed to get dbus connection: Error calling StartServiceByName for org.mate.ScreenSaver: Process org.mate.ScreenSaver received signal 11

(mate-notification-daemon:228742): GLib-GIO-CRITICAL **: 17:44:23.295: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed
malloc(): unaligned fastbin chunk detected
malloc(): unaligned tcache chunk detected
Aborted (core dumped)
[sb-wayland@mother ~]$ 

Second terminal:

[sb-wayland@mother ~]$ notify-send Hallo
GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
[sb-wayland@mother ~]$ 

Honestly, i prefer my current solution. Edit: Or we drop dbus-activation, but than we can't restart the daemon.

[cwendling]

@cwendling I didn't call for help, i know to fetch a branch. I only wanted to blame you :P

Fair enough :grin:

I tested your branch. It seems to work in x11 mate-session but it doesn't work in wayland session, which was my first intention for all this work. Here the daemon crashes when i use notify-send command. […]

I really don't understand what could cause my take to be worse than yours particularly on Wayland, it has zero code specific to one or the other; and if you run it without arguments it should behave the same. Could you get a backtrace so we can see what the actual issue is?

While I don't particularly care if we drop the D-Bus activation entirely given we have fixed all cases that could be problematic (and while we should fix any crash in the daemon itself, not being able to restart it automatically if it does crash is not great) beyond what I already mentioned, but I would really prefer that if we are D-Bus-activated we do idle exit, because it's actually one of the main advantages activation has: the software can come and go as needed, not wasting resources when unused.

[edit] PS: I won't be able to test anything Wayland in the near future, if we go that route I'll have to setup a VM for this, but I won't have time before October at the earliest…

[raveit65]

Only a minimal stacktrace because my cable landline is broken today and i am connected with my cell phone, so i can't download huge debuginfo packages.

[sb-wayland@mother ~]$ gdb /usr/libexec/mate-notification-daemon
GNU gdb (GDB) Fedora Linux 13.2-2.fc38

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/libexec/mate-notification-daemon 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff5d3c6c0 (LWP 248418)]
[New Thread 0x7ffff553b6c0 (LWP 248419)]
[New Thread 0x7ffff4d3a6c0 (LWP 248420)]
[New Thread 0x7fffe7fff6c0 (LWP 248421)]
[New Thread 0x7fffe77fe6c0 (LWP 248422)]
[New Thread 0x7fffe6ffd6c0 (LWP 248453)]
[Thread 0x7fffe6ffd6c0 (LWP 248453) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 248454)]
[New Thread 0x7fffe67fc6c0 (LWP 248455)]
[Thread 0x7fffe6ffd6c0 (LWP 248454) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 248456)]
[New Thread 0x7fffe5ffb6c0 (LWP 248457)]
[Thread 0x7fffe67fc6c0 (LWP 248455) exited]
[Thread 0x7fffe6ffd6c0 (LWP 248456) exited]
[Thread 0x7fffe5ffb6c0 (LWP 248457) exited]

** (mate-notification-daemon:248408): WARNING **: 18:30:06.329: Failed to get dbus connection: Error calling StartServiceByName for org.mate.ScreenSaver: Process org.mate.ScreenSaver received signal 11

(mate-notification-daemon:248408): GLib-GIO-CRITICAL **: 18:30:06.329: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed

Thread 5 "gdbus" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe7fff6c0 (LWP 248421)]
0x00007ffff72f7bce in g_atomic_ref_count_inc () from /lib64/libglib-2.0.so.0
(gdb) thread apply all bt full

Thread 6 (Thread 0x7fffe77fe6c0 (LWP 248422) "dconf worker"):
#0  0x00007ffff706535d in poll () at /lib64/libc.so.6
#1  0x00007ffff733f5b9 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007ffff72deb13 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007ffff7fa85c5 in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#6  0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 5 (Thread 0x7fffe7fff6c0 (LWP 248421) "gdbus"):
#0  0x00007ffff72f7bce in g_atomic_ref_count_inc () at /lib64/libglib-2.0.so.0
#1  0x00007ffff732a63e in g_variant_ref () at /lib64/libglib-2.0.so.0
#2  0x00007ffff7332dbd in g_variant_get_child_value () at /lib64/libglib-2.0.so.0
#3  0x00007ffff7332f64 in g_variant_valist_get () at /lib64/libglib-2.0.so.0
#4  0x00007ffff73334e0 in g_variant_get_va () at /lib64/libglib-2.0.so.0
#5  0x00007ffff7333659 in g_variant_get () at /lib64/libglib-2.0.so.0
#6  0x00007ffff75411f7 in g_dbus_message_new_from_blob () at /lib64/libgio-2.0.so.0
#7  0x00007ffff755009b in _g_dbus_worker_do_read_cb () at /lib64/libgio-2.0.so.0
#8  0x00007ffff74e009c in g_task_return_now () at /lib64/libgio-2.0.so.0
#9  0x00007ffff74e00d5 in complete_in_idle_cb () at /lib64/libgio-2.0.so.0
#10 0x00007ffff72dd48d in g_idle_dispatch () at /lib64/libglib-2.0.so.0
#11 0x00007ffff72e148c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#12 0x00007ffff733f648 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#13 0x00007ffff72e0a8f in g_main_loop_run () at /lib64/libglib-2.0.so.0
#14 0x00007ffff75484b2 in gdbus_shared_thread_func.lto_priv () at /lib64/libgio-2.0.so.0
#15 0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#16 0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#17 0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 4 (Thread 0x7ffff4d3a6c0 (LWP 248420) "pool-mate-notif"):
#0  0x00007ffff706ab5d in syscall () at /lib64/libc.so.6
#1  0x00007ffff7337040 in g_cond_wait_until () at /lib64/libglib-2.0.so.0
#2  0x00007ffff72ac103 in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3  0x00007ffff72ac256 in g_async_queue_timeout_pop () at /lib64/libglib-2.0.so.0
#4  0x00007ffff7311f3f in g_thread_pool_thread_proxy.lto_priv () at /lib64/libglib-2.0.so.0
#5  0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#6  0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#7  0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 3 (Thread 0x7ffff553b6c0 (LWP 248419) "gmain"):
--Type <RET> for more, q to quit, c to continue without paging--c
#0  0x00007ffff706535d in poll () at /lib64/libc.so.6
#1  0x00007ffff733f5b9 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007ffff72deb13 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007ffff72deb69 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#6  0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 2 (Thread 0x7ffff5d3c6c0 (LWP 248418) "pool-spawner"):
#0  0x00007ffff706ab5d in syscall () at /lib64/libc.so.6
#1  0x00007ffff733674d in g_cond_wait () at /lib64/libglib-2.0.so.0
#2  0x00007ffff72ac13b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3  0x00007ffff7311563 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0
#4  0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#6  0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 1 (Thread 0x7ffff5d3da40 (LWP 248408) "mate-notificati"):
#0  0x00007ffff6cdc97a in _cairo_tor_scan_converter_generate.lto_priv.0 () at /lib64/libcairo.so.2
#1  0x00007ffff6ccec31 in composite_polygon () at /lib64/libcairo.so.2
#2  0x00007ffff6cd1733 in _cairo_spans_compositor_fill.lto_priv.0 () at /lib64/libcairo.so.2
#3  0x00007ffff6c89c52 in _cairo_compositor_fill () at /lib64/libcairo.so.2
#4  0x00007ffff6c9acda in _cairo_image_surface_fill () at /lib64/libcairo.so.2
#5  0x00007ffff6cd9239 in _cairo_surface_fill () at /lib64/libcairo.so.2
#6  0x00007ffff6c8fae4 in _cairo_gstate_fill () at /lib64/libcairo.so.2
#7  0x00007ffff6c8fc06 in _cairo_default_context_fill () at /lib64/libcairo.so.2
#8  0x00007ffff6ce6641 in cairo_fill () at /lib64/libcairo.so.2
#9  0x00007ffff431ebb0 in draw_stripe (widget=<optimized out>, cr=0x5555557cf970, windata=0x5555555c5be0) at /usr/src/debug/mate-notification-daemon-1.27.1-1.fc38.x86_64/src/themes/nodoka/nodoka-theme.c:476
        color_mult = 1
        top_color = {red = 0.078431372549019607, green = 0.68627450980392157, blue = 1, alpha = <optimized out>}
        bottom_color = {red = 0, green = 0.38039215686274508, blue = 0.57647058823529407, alpha = <optimized out>}
        alpha = 0.92000000000000004
        pattern = 0x5555556dbe70
        cr2 = 0x5555557cf970
        surface = 0x5555555dda70
        allocation = {x = 1433307328, y = 21845, width = 1433136736, height = 21845}
#10 paint_window (widget=<optimized out>, windata=0x5555555c5be0, cr=0x5555557ceb30) at /usr/src/debug/mate-notification-daemon-1.27.1-1.fc38.x86_64/src/themes/nodoka/nodoka-theme.c:604
        cr2 = 0x5555557cf970
        surface = 0x5555555dda70
        allocation = {x = 1433307328, y = 21845, width = 1433136736, height = 21845}
#11 on_draw (widget=<optimized out>, cr=0x5555557ceb30, windata=0x5555555c5be0) at /usr/src/debug/mate-notification-daemon-1.27.1-1.fc38.x86_64/src/themes/nodoka/nodoka-theme.c:622
#12 0x00007ffff76a1244 in _gtk_marshal_BOOLEAN__STRING.part.0 () at /lib64/libgtk-3.so.0
#13 0x00007ffff79552a6 in gtk_widget_draw_marshaller () at /lib64/libgtk-3.so.0
#14 0x00007ffff73e24ea in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#15 0x00007ffff7410e16 in signal_emit_unlocked_R.isra.0 () at /lib64/libgobject-2.0.so.0
#16 0x00007ffff74017e2 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#17 0x00007ffff7401f33 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#18 0x00007ffff7966ae1 in gtk_widget_draw_internal () at /lib64/libgtk-3.so.0
#19 0x00007ffff771f242 in gtk_container_propagate_draw () at /lib64/libgtk-3.so.0
#20 0x00007ffff771f354 in gtk_container_draw () at /lib64/libgtk-3.so.0
#21 0x00007ffff79669d4 in gtk_widget_draw_internal () at /lib64/libgtk-3.so.0
#22 0x00007ffff796bfdf in gtk_widget_render () at /lib64/libgtk-3.so.0
#23 0x00007ffff7809610 in gtk_main_do_event () at /lib64/libgtk-3.so.0
#24 0x00007ffff7e42427 in _gdk_event_emit () at /lib64/libgdk-3.so.0
#25 0x00007ffff7e54749 in _gdk_window_process_updates_recurse_helper.lto_priv.0 () at /lib64/libgdk-3.so.0
#26 0x00007ffff7e58d55 in gdk_window_process_updates_internal () at /lib64/libgdk-3.so.0
#27 0x00007ffff7e58f61 in gdk_window_process_updates_with_mode.lto_priv () at /lib64/libgdk-3.so.0
#28 0x00007ffff7401dba in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#29 0x00007ffff7401f33 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#30 0x00007ffff7e4f948 in gdk_frame_clock_paint_idle () at /lib64/libgdk-3.so.0
#31 0x00007ffff7e3bc8d in gdk_threads_dispatch () at /lib64/libgdk-3.so.0
#32 0x00007ffff72e1d59 in g_timeout_dispatch () at /lib64/libglib-2.0.so.0
#33 0x00007ffff72e148c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#34 0x00007ffff733f648 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#35 0x00007ffff72e0a8f in g_main_loop_run () at /lib64/libglib-2.0.so.0
#36 0x00007ffff7806975 in gtk_main () at /lib64/libgtk-3.so.0
#37 0x000055555555ce19 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/mate-notification-daemon-1.27.1-1.fc38.x86_64/src/daemon/mnd-daemon.c:107
        daemon = 0x5555556830c0
(gdb) Quit
(gdb) 

Maybe @lukefromdc is more lucky to test this under wayfire.

[cwendling]

Wait, you edited your backtrace, which it totally different now!?

Anyway, this does not seem at all related to my changes vs. yours, can you verify this indeed works flawlessly with yours!??

Anyway, what about this (for your pre-edit backtrace):

diff --git a/src/daemon/daemon.c b/src/daemon/daemon.c
index fd5d3f3..a9b63f5 100644
--- a/src/daemon/daemon.c
+++ b/src/daemon/daemon.c
@@ -1140,6 +1140,7 @@ static gboolean screensaver_active(GtkWidget* nw)
    if (proxy == NULL) {
        g_warning("Failed to get dbus connection: %s", error->message);
        g_error_free (error);
+       return active;
    }

    variant = g_dbus_proxy_call_sync (proxy,

[lukefromdc]

Installing and then uninstalling all of KDE on my bare metal setup would be a bandwidth and a cleanup problem, but about to test this on wayfire to see if I can duplicate that crash

[raveit65]

It is the same crash , i only installed the local m-n-d-debuginfo package. Once again:

[sb-wayland@mother ~]$ gdb /usr/libexec/mate-notification-daemon
GNU gdb (GDB) Fedora Linux 13.2-2.fc38
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/libexec/mate-notification-daemon...
Reading symbols from /usr/lib/debug/usr/libexec/mate-notification-daemon-1.27.1-1.fc38.x86_64.debug...
(gdb) run
Starting program: /usr/libexec/mate-notification-daemon 

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff5d3c6c0 (LWP 253523)]
[New Thread 0x7ffff553b6c0 (LWP 253524)]
[New Thread 0x7ffff4d3a6c0 (LWP 253525)]
[New Thread 0x7fffe7fff6c0 (LWP 253526)]
[New Thread 0x7fffe77fe6c0 (LWP 253527)]
[New Thread 0x7fffe6ffd6c0 (LWP 253597)]
[Thread 0x7fffe6ffd6c0 (LWP 253597) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 253598)]
[New Thread 0x7fffe67fc6c0 (LWP 253599)]
[Thread 0x7fffe6ffd6c0 (LWP 253598) exited]
[New Thread 0x7fffe6ffd6c0 (LWP 253600)]
[New Thread 0x7fffe5ffb6c0 (LWP 253601)]
[Thread 0x7fffe67fc6c0 (LWP 253599) exited]
[Thread 0x7fffe6ffd6c0 (LWP 253600) exited]
[Thread 0x7fffe5ffb6c0 (LWP 253601) exited]

** (mate-notification-daemon:253489): WARNING **: 18:44:40.267: Failed to get dbus connection: Error calling StartServiceByName for org.mate.ScreenSaver: Process org.mate.ScreenSaver received signal 11

(mate-notification-daemon:253489): GLib-GIO-CRITICAL **: 18:44:40.267: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed

Thread 5 "gdbus" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe7fff6c0 (LWP 253526)]
0x00007ffff72f7bce in g_atomic_ref_count_inc () from /lib64/libglib-2.0.so.0
Missing separate debuginfos, use: dnf debuginfo-install at-spi2-atk-2.48.3-1.fc38.x86_64 at-spi2-core-2.48.3-1.fc38.x86_64 atk-2.48.3-1.fc38.x86_64 bzip2-libs-1.0.8-13.fc38.x86_64 cairo-1.17.8-4.fc38.x86_64 cairo-gobject-1.17.8-4.fc38.x86_64 dbus-libs-1.14.8-1.fc38.x86_64 dconf-0.40.0-8.fc38.x86_64 fontconfig-2.14.2-1.fc38.x86_64 freetype-2.13.0-2.fc38.x86_64 fribidi-1.0.12-3.fc38.x86_64 gdk-pixbuf2-2.42.10-2.fc38.x86_64 glib2-2.76.4-3.fc38.x86_64 glibc-2.37-4.fc38.x86_64 graphite2-1.3.14-11.fc38.x86_64 gtk-layer-shell-0.8.1-1.fc38.x86_64 gtk3-3.24.38-1.fc38.x86_64 gvfs-client-1.50.5-2.fc38.x86_64 harfbuzz-7.1.0-1.fc38.x86_64 json-glib-1.6.6-4.fc38.x86_64 libX11-1.8.6-1.fc38.x86_64 libX11-xcb-1.8.6-1.fc38.x86_64 libXau-1.0.11-2.fc38.x86_64 libXcomposite-0.4.5-9.fc38.x86_64 libXcursor-1.2.1-3.fc38.x86_64 libXdamage-1.1.5-9.fc38.x86_64 libXext-1.3.5-2.fc38.x86_64 libXfixes-6.0.0-5.fc38.x86_64 libXi-1.8.1-1.fc38.x86_64 libXinerama-1.1.5-2.fc38.x86_64 libXrender-0.9.11-2.fc38.x86_64 libXres-1.2.1-4.fc38.x86_64 libblkid-2.38.1-4.fc38.x86_64 libcanberra-gtk3-0.30-31.fc38.x86_64 libcap-2.48-6.fc38.x86_64 libcloudproviders-0.3.1-7.fc38.x86_64 libdatrie-0.2.13-5.fc38.x86_64 libepoxy-1.5.10-3.fc38.x86_64 libffi-3.4.4-2.fc38.x86_64 libgcc-13.2.1-1.fc38.x86_64 libjpeg-turbo-2.1.4-2.fc38.x86_64 libmount-2.38.1-4.fc38.x86_64 libogg-1.3.5-5.fc38.x86_64 libpng-1.6.37-14.fc38.x86_64 libtdb-1.4.8-1.fc38.x86_64 libthai-0.1.29-4.fc38.x86_64 libvorbis-1.3.7-7.fc38.x86_64 libwayland-client-1.22.0-1.fc38.x86_64 libwayland-cursor-1.22.0-1.fc38.x86_64 libwayland-egl-1.22.0-1.fc38.x86_64 libwnck3-43.1-1.fc38.x86_64 libxcb-1.13.1-11.fc38.x86_64 libxkbcommon-1.5.0-2.fc38.x86_64 lz4-libs-1.9.4-2.fc38.x86_64 pango-1.50.14-1.fc38.x86_64 pcre2-10.42-1.fc38.1.x86_64 pixman-0.42.2-1.fc38.x86_64 sqlite-libs-3.40.1-2.fc38.x86_64 startup-notification-0.12-25.fc38.x86_64 xcb-util-0.4.1-2.fc38.x86_64 xz-libs-5.4.1-1.fc38.x86_64 zlib-1.2.13-3.fc38.x86_64
(gdb) thread apply all bt full

Thread 6 (Thread 0x7fffe77fe6c0 (LWP 253527) "dconf worker"):
#0  0x00007ffff706535d in poll () at /lib64/libc.so.6
#1  0x00007ffff733f5b9 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007ffff72deb13 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007ffff7fa85c5 in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#6  0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 5 (Thread 0x7fffe7fff6c0 (LWP 253526) "gdbus"):
#0  0x00007ffff72f7bce in g_atomic_ref_count_inc () at /lib64/libglib-2.0.so.0
#1  0x00007ffff732a63e in g_variant_ref () at /lib64/libglib-2.0.so.0
#2  0x00007ffff7332dbd in g_variant_get_child_value () at /lib64/libglib-2.0.so.0
#3  0x00007ffff7332f64 in g_variant_valist_get () at /lib64/libglib-2.0.so.0
#4  0x00007ffff73334e0 in g_variant_get_va () at /lib64/libglib-2.0.so.0
#5  0x00007ffff7333659 in g_variant_get () at /lib64/libglib-2.0.so.0
#6  0x00007ffff75411f7 in g_dbus_message_new_from_blob () at /lib64/libgio-2.0.so.0
#7  0x00007ffff755009b in _g_dbus_worker_do_read_cb () at /lib64/libgio-2.0.so.0
#8  0x00007ffff74e009c in g_task_return_now () at /lib64/libgio-2.0.so.0
#9  0x00007ffff74e00d5 in complete_in_idle_cb () at /lib64/libgio-2.0.so.0
#10 0x00007ffff72dd48d in g_idle_dispatch () at /lib64/libglib-2.0.so.0
#11 0x00007ffff72e148c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#12 0x00007ffff733f648 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#13 0x00007ffff72e0a8f in g_main_loop_run () at /lib64/libglib-2.0.so.0
#14 0x00007ffff75484b2 in gdbus_shared_thread_func.lto_priv () at /lib64/libgio-2.0.so.0
#15 0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#16 0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#17 0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 4 (Thread 0x7ffff4d3a6c0 (LWP 253525) "pool-mate-notif"):
#0  0x00007ffff706ab5d in syscall () at /lib64/libc.so.6
#1  0x00007ffff7337040 in g_cond_wait_until () at /lib64/libglib-2.0.so.0
#2  0x00007ffff72ac103 in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3  0x00007ffff72ac256 in g_async_queue_timeout_pop () at /lib64/libglib-2.0.so.0
#4  0x00007ffff7311f3f in g_thread_pool_thread_proxy.lto_priv () at /lib64/libglib-2.0.so.0
#5  0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#6  0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#7  0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 3 (Thread 0x7ffff553b6c0 (LWP 253524) "gmain"):
--Type <RET> for more, q to quit, c to continue without paging--c
#0  0x00007ffff706535d in poll () at /lib64/libc.so.6
#1  0x00007ffff733f5b9 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007ffff72deb13 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007ffff72deb69 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#6  0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 2 (Thread 0x7ffff5d3c6c0 (LWP 253523) "pool-spawner"):
#0  0x00007ffff706ab5d in syscall () at /lib64/libc.so.6
#1  0x00007ffff733674d in g_cond_wait () at /lib64/libglib-2.0.so.0
#2  0x00007ffff72ac13b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3  0x00007ffff7311563 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0
#4  0x00007ffff730f983 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff6fec907 in start_thread () at /lib64/libc.so.6
#6  0x00007ffff7072870 in clone3 () at /lib64/libc.so.6

Thread 1 (Thread 0x7ffff5d3da40 (LWP 253489) "mate-notificati"):
#0  0x00007ffff640d9a2 in _pixman_gradient_walker_fill_narrow () at /lib64/libpixman-1.so.0
#1  0x00007ffff6422d60 in linear_get_scanline.lto_priv () at /lib64/libpixman-1.so.0
#2  0x00007ffff640e4b6 in general_composite_rect.lto_priv () at /lib64/libpixman-1.so.0
#3  0x00007ffff63db35b in pixman_image_composite32 () at /lib64/libpixman-1.so.0
#4  0x00007ffff6c986eb in _inplace_spans () at /lib64/libcairo.so.2
#5  0x00007ffff6cdc8b6 in _cairo_tor_scan_converter_generate.lto_priv.0 () at /lib64/libcairo.so.2
#6  0x00007ffff6ccec31 in composite_polygon () at /lib64/libcairo.so.2
#7  0x00007ffff6cd12f5 in _cairo_spans_compositor_stroke.lto_priv.0 () at /lib64/libcairo.so.2
#8  0x00007ffff6c8997d in _cairo_compositor_stroke_impl.lto_priv.0 () at /lib64/libcairo.so.2
#9  0x00007ffff6c9ac9f in _cairo_image_surface_stroke () at /lib64/libcairo.so.2
#10 0x00007ffff6cd89c0 in _cairo_surface_stroke () at /lib64/libcairo.so.2
#11 0x00007ffff6c8f08b in _cairo_gstate_stroke () at /lib64/libcairo.so.2
#12 0x00007ffff6c8f4b6 in _cairo_default_context_stroke () at /lib64/libcairo.so.2
#13 0x00007ffff6ce65a1 in cairo_stroke () at /lib64/libcairo.so.2
#14 0x00007ffff431e9f1 in draw_border (widget=<optimized out>, cr=0x5555558701a0, windata=0x5555555c9530) at /usr/src/debug/mate-notification-daemon-1.27.1-1.fc38.x86_64/src/themes/nodoka/nodoka-theme.c:505
        alpha = 0.92000000000000004
        pattern = 0x5555555d85d0
        cr2 = 0x5555558701a0
        surface = 0x5555556c4f40
        allocation = {x = 1432333136, y = 21845, width = 1434262784, height = 21845}
#15 paint_window (widget=<optimized out>, windata=0x5555555c9530, cr=0x555555873430) at /usr/src/debug/mate-notification-daemon-1.27.1-1.fc38.x86_64/src/themes/nodoka/nodoka-theme.c:603
        cr2 = 0x5555558701a0
        surface = 0x5555556c4f40
        allocation = {x = 1432333136, y = 21845, width = 1434262784, height = 21845}
#16 on_draw (widget=<optimized out>, cr=0x555555873430, windata=0x5555555c9530) at /usr/src/debug/mate-notification-daemon-1.27.1-1.fc38.x86_64/src/themes/nodoka/nodoka-theme.c:622
#17 0x00007ffff76a1244 in _gtk_marshal_BOOLEAN__STRING.part.0 () at /lib64/libgtk-3.so.0
#18 0x00007ffff79552a6 in gtk_widget_draw_marshaller () at /lib64/libgtk-3.so.0
#19 0x00007ffff73e24ea in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#20 0x00007ffff7410e16 in signal_emit_unlocked_R.isra.0 () at /lib64/libgobject-2.0.so.0
#21 0x00007ffff74017e2 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#22 0x00007ffff7401f33 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#23 0x00007ffff7966ae1 in gtk_widget_draw_internal () at /lib64/libgtk-3.so.0
#24 0x00007ffff771f242 in gtk_container_propagate_draw () at /lib64/libgtk-3.so.0
#25 0x00007ffff771f354 in gtk_container_draw () at /lib64/libgtk-3.so.0
#26 0x00007ffff79669d4 in gtk_widget_draw_internal () at /lib64/libgtk-3.so.0
#27 0x00007ffff796bfdf in gtk_widget_render () at /lib64/libgtk-3.so.0
#28 0x00007ffff7809610 in gtk_main_do_event () at /lib64/libgtk-3.so.0
#29 0x00007ffff7e42427 in _gdk_event_emit () at /lib64/libgdk-3.so.0
#30 0x00007ffff7e54749 in _gdk_window_process_updates_recurse_helper.lto_priv.0 () at /lib64/libgdk-3.so.0
#31 0x00007ffff7e58d55 in gdk_window_process_updates_internal () at /lib64/libgdk-3.so.0
#32 0x00007ffff7e58f61 in gdk_window_process_updates_with_mode.lto_priv () at /lib64/libgdk-3.so.0
#33 0x00007ffff7401dba in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#34 0x00007ffff7401f33 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#35 0x00007ffff7e4f948 in gdk_frame_clock_paint_idle () at /lib64/libgdk-3.so.0
#36 0x00007ffff7e3bc8d in gdk_threads_dispatch () at /lib64/libgdk-3.so.0
#37 0x00007ffff72e1d59 in g_timeout_dispatch () at /lib64/libglib-2.0.so.0
#38 0x00007ffff72e148c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#39 0x00007ffff733f648 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#40 0x00007ffff72e0a8f in g_main_loop_run () at /lib64/libglib-2.0.so.0
#41 0x00007ffff7806975 in gtk_main () at /lib64/libgtk-3.so.0
#42 0x000055555555ce19 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/mate-notification-daemon-1.27.1-1.fc38.x86_64/src/daemon/mnd-daemon.c:107
        daemon = 0x555555741500
(gdb) 

[cwendling]

It didn't look the same, as it was thread1 that was crashing then, rather than the "gdbus" one. Anyway, please try my one-line patch, it should help some -- not saying it would fix it all though.

[raveit65]

I always rebuild an rpm so i need a patch. I can later generate a patch for my self when i found time. Edit: Opps, it is already a diff.

....i need a timeout :)

[lukefromdc]

This just worked fine on my end, though restarting by calling the daemon after terminating it works only on Xorg. Will have to try it with an SDDM wayfire session, and all four themes to try and duplicate the crash

[raveit65]

@lukefromdc You did use this branch? https://github.com/mate-desktop/mate-notification-daemon/commits/start-with-session

[cwendling]

@raveit65 ah, you realized (my turn! :D) Anyway, I pushed it to the branch if it makes it easier for you.

[lukefromdc]

NOT sure, I used the main branch of this PR and it is getting confusing

[lukefromdc]

OK, git gui was able to find https://github.com/mate-desktop/mate-notification-daemon/commits/start-with-session and so long as I have my wayland session autostarting the daemon it works fine there with the latest changes (no crash). Note that "enable do not disturb" must be turned OFF for notifications to show even though the tray applet (a status icon) is not used in wayland

[raveit65]

NOT sure, I used the main branch of this PR and it is getting confusing

Yeah, the branch from my PR works great. The other branch is from @cwendling which is different and i got the crash with it under wayfire

[lukefromdc]

That one worked too on my end with the 3ed commit applied

[raveit65]

@cwendling Go ahead and open a pull request with your branch, i am too lazy to adopt your commits to this branch :) The crash in wayfire is gone with latest commit. Very weird that m-n-d can crash when mate-screensaver isn't used. You fixed a hidden bug :) Your branch works well in my VM with kde installed. M-N-D works well until it is killed. Restarting with dbus-activation doesn't work here of course. The change can describe like this. We switched to auto start the daemon to make mate session save when other notification daemons are installed. As fallback we use dbus-actvation when the daemon stopped working. @yselkowitz I know this is not what you expected and it doesn't solve the issue in general. But with removing dbus-activation we can't restart the daemon automatically. Feel free to open a PR wich adds session-mangement by libsm to m-n-d, than we can remove dbus-activation and restart the daemon with X-MATE-AutoRestart=true in desktop file.

Beside from this i am thinking why we should remove dbus-activation when all other DEs except gnome gives a shit about?

[cwendling]

Go ahead and open a pull request with your branch, i am too lazy to adopt your commits to this branch :)

If it's laziness… I just hijacked your PR not to make a 3rd one scattering discussion.

The crash in wayfire is gone with latest commit. Very weird that m-n-d can crash when mate-screensaver isn't used. You fixed a hidden bug :)

Yeah, that was a weird bug… probably nobody ever had a situation where the m-n-d dbus service worked but not the screensaver I suppose.

Your branch works well in my VM with kde installed. M-N-D works well until it is killed. Restarting with dbus-activation doesn't work here of course.

Great, thanks for testing again.