Comment 1 for bug 1023166

As a short fix you can do:
$ killall notification-daemon
when you recognize issue.

This will stop the notification-daemon and start it "fresh" on next notification.

The problem is with notification-daemon. It has a hard-coded limit of 20. This is, AFAIK, how many messages can be in the queue simultaneously. Problem is that when notifications close by them selves the queue is not updated properly.

However: If I _manually_ close each message, by clicking the [x] on the notification, the g_hash_table_size(daemon->priv->queue) is updated. On my system it seems to be a limit of 22 - or by "some magic" two of the messages get removed.

A quick-hack (not a fix) is to run a script to kill the daemon on error. E.g:

$HOME/bin/notify-limit-err-kill

[Code]:

#!/bin/bash

debug=0

dbus-monitor "type='error'" |
while read buf; do
 ((debug)) && printf >&2 "MESSG: %-40s\n" "$buf"
 if [[ "$buf" == 'string "Exceeded maximum number of notifications"' ]]; then
  killall notification-daemon
 fi
done

[EOF Code]

$ chmod +x notify-limit-err-kill
And add it as a startup script (or launch it manually).

You will, however, by this, loose the one notification that caused the error.
I have a script for catching this as well, and re-transmitting after spawn of daemon - but code is a bit ugly ...