notify-send sometimes stops working until mako is restarted

[revsuine]

I've noticed that sometimes notify-send stops working (ie no mako notification appears) until mako is restarted using SIGTERM and then executing mako again.

Using:

dbus-run-session river

to run my graphical session

I do riverctl spawn mako in my River (classic, 0.3.14) init to run mako.

libnotify is version 0.8.8

mako is version 1.10.0

OS is Artix Linux x86_64; packages are up to date.

notify-send is being invoked by various programs, including me opening my terminal emulator and running notify-send on there.

Notifications sent by some applications are appearing (Firefox and Discord), which I assume are not using libnotify. But trying to do notify-send does nothing. notify-send completes with exit code 0/no errors, but no notification appears.

Any ideas? This might not be a mako bug, but given that restarting mako fixes it, I thought here would be a good starting point for figuring this out.

[aivarsV]

I have had the same issue for one or two months already on similar setup. River classic session on Arch linux. I just hadn't had time to look into this before.

So far I've discovered, that only notify-send doesn't break mako. Everything else, that calls D-bus directly, like firefox or gopass can reproduce this issue (at least on my machine).

Dumped D-bus log, and it seems, that, although new notifications are not shown, mako does answer over D-bus. Also, makoctl history shows new notifications, as they are sent over to mako.

Notification 63: something
  App name: notify-send
  Urgency: normal
Notification 62: gopass - clipboard
  App name: gopass
Notification 61: something          <----- This one was last shown notification
  App name: notify-send
  Urgency: normal
Notification 60: Mail sync
  App name: notify-send
  Urgency: normal
Notification 59: Syncing mails
  App name: notify-send
  Urgency: normal
 ~  $

dbus.log

[OutOfContainment]

+1
After updating from river-0.3.7_1 (Void repo) to local river-classic-0.3.14 installation I started experiencing very inconsistent behavior with mako, as described above.
Despite river-classic being the obvious culprit here, I still suspect it is a mako issue since other notification daemons I tested (fnott, dunst) work as expected.

Note: this only happens when I let dbus handle mako initialization. Executing mako manually from river config fixes this issue (I do not use dbus-run-session). UPD: Executing mako manually does not fix the issue but changes behaviour patterns (some apps work, some don't?).