Notifications Hang system and use 100% CPU [$65]

[silver-dragon]

When ever I get a notification from the daemon it causes the computer to slow way down and when I check the processes I see that the is using 100% of the cpu. The computer will return to normal after a sigterm the process. Most of my notifications come from Opera browser I don't know if there is a related compatibility issue. Screenshot -> https://www.dropbox.com/s/rwpa95enw9syegy/mate-notification-daemon-crash.png?raw=1

--- Did you help close this issue? Go claim the **[$65 bounty](https://www.bountysource.com/issues/38648165-notifications-hang-system-and-use-100-cpu?utm_campaign=plugin&utm_content=tracker%2F1172660&utm_medium=issues&utm_source=github)** on [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1172660&utm_medium=issues&utm_source=github).

[absemetov]

Linux Mint 18.1, 64bit ThinkPad x121e In addition, I have the upper right corner desktop not working After killing daemon, mouse starts to click in this area

[iamanikeev]

Had the same issue just now, reproduced it when enabled notifications in Opera, and received a notification from a pinned telegram.web tab. Other notifications (e.g. from Slack) didn't cause this issue.

Linux Mint 18 Sarah \n \l
ii  mate-notification-daemo 1.14.0-1+sarah   amd64            daemon to display passive popup notifications

[Finwood]

Same here. Reproducible from Opera with Telegram, Slack and WhatsApp notifications.

_Linux Mint 18.1 Serena (4.4.0-53-generic x8664), MATE 1.16.1, Opera 43.0.2442.1144

[jing2uo]

Same here. wechat, wx.qq.com. Tks~

[glum-psyche]

The same issue. All Opera notifications cause the overhead.

_Ubuntu 16.04.1 (4.8.0-57-genericx 8664), MATE 1.16.2, Opera 46.0.2597.26

[rotchajunior]

Same here. Opera and Rambox notifications.

Ubuntu 17.04, Opera 46.0.2597.57

[p-m]

Steps to reproduce:

1.) On an openSUSE Leap 42.3 system, install packages emacs-x11, fvwm and mate-notification-daemon.

2.) Start fvwm session.

3.) Start this command: emacs -Q --eval "(progn (require 'notifications) (notifications-notify :title \"Test\" :timeout 2200000 :actions '(\"one\" \"two\")))"

Result: mate-notification-daemon hangs with 100% CPU utilisation.

Peter

[snaiperskaya96]

Please have a look at the linked PR and let me know (#122)

[p-m]

Could you please send the commands for building with your pull-request? Something like: git clone ulr git merge your-pull-request ./configure make

TIA, Peter

[snaiperskaya96]

Nothing really different form the usual mate-notification-daemon process. I believe you can build it by doing something like this:

git clone https://github.com/snaiperskaya96/mate-notification-daemon.git
cd mate-notification-daemon
git checkout opera-notifications-memory-leak
./autogen.sh
make
sudo make install

There might be a few dependencies to install that i cannot actually remember, just post here if you need some help :)

Also please close the old process if there is any active and consider rebooting/reloading the session if you cannot notice any change

[p-m]

On Tue, Aug 08 2017, Jury Verrigni wrote:

git checkout opera-notifications-memory-leak

Thanks, seems to be easy to compile a PR.

The daemon does no more hang, but there is no more sand-glass, that indicates the remaining time. (I use the Nodoka theme.)

Thanks, Peter

[snaiperskaya96]

Ignore my previous theories. I came to the conclusion that the problem was due to opera setting the timeout to MAX_INT instead of 0 to make an endless notification, i think. Should be definitely fixed now.

[p-m]

On Wed, Aug 09 2017, Jury Verrigni wrote:

Should be definitely fixed now.

It seems, that there is still a problem with the Nodoka theme. The daemon hangs with 100% CPU usage. Please try this:

emacs -Q --eval "(progn (require 'notifications) (notifications-notify :title \"Test\" :timeout 2200000 :actions '(\"key\" \"text\")) (kill-emacs))"

No problem with timeout = 2100000.

-- Peter

[snaiperskaya96]

True, I think we should deal with realistic timeouts though. Using 30 minutes instead of 0 (infinite) sounds silly to me, i think we should discuss with the team to limit this to, say, 20 minutes and eventually set the timeout to 0 if > 20 minutes.

Edit: Looks like the hard limit is 2147483, which are the first digits of MAX_INT. Will set a limit to it

[p-m]

On Wed, Aug 09 2017, Jury Verrigni wrote:

True, I think we should deal with realistic timeouts though. Using 30 minutes instead of 0 (infinite) sounds silly to me,

There are use cases where this is not silly. Sometimes I use a timeout of 2 hours or similar.

Since there is really no reason, why this should not work, I've investigated myself. Please find here the patch, that solves the issue:

diff --git a/src/daemon/daemon.c b/src/daemon/daemon.c index 72b94a4..4b81c3c 100644 --- a/src/daemon/daemon.c +++ b/src/daemon/daemon.c @@ -743,7 +743,7 @@ static void _calculate_timeout(NotifyDaemon daemon, NotifyTimeout nt, int time

    theme_set_notification_timeout(nt->nw, timeout);

• glong usec = timeout 1000; / convert from msec to usec */

• glong usec = timeout 1000L; / convert from msec to usec */

  /*
   * If it's less than 0, wrap around back to MAXLONG.

-- Peter

[snaiperskaya96]

Works flawlessy, i completely mislooked at it. Thank you, will push this change instead of mines

[snaiperskaya96]

Sorry about the claim, thought it was other stuff on caja :)

[monsta]

The fix is now released in version 1.18.1.