Dunst: timeout beyond ~10 minutes does not work

[mithodin]

I'm trying to have a notification time out at n minutes by calling notify-send -t $(( 60000*$n )) "some message". This works correctly for n <= 10, but fails for n >= 15 (I could pinpoint it further if neccessary) in the sense that the notification just keeps showing after the supposed timeout.

I have checked with dbus-monitor, and the transmitted information seems correct in all cases, so I suspect that this is a bug in dunst and not somewhere else.

Installation info

• Version: v1.4.1
• Install type: package or manual
• Distro and version: linux mint 19.2, kernel 5.0.0

[bebehei]

We had a similar bug 2 weeks ago. Does the current master work? (PR #647 fixed it).

What does dunst -print say when running dunst on the command line. and sending a notification in parallel?

[mithodin]

{
    appname: 'notify-send'
    summary: '15 minute timeout'
    body: ''
    icon: 'dialog-information'
    raw_icon set: false
    icon_id: 'dialog-information'
    desktop_entry: ''
    category:
    timeout: 900000
    urgency: NORMAL
    transient: 0
    formatted: '<b>15 minute timeout</b>'
    fg: #ffffff
    bg: #285577
    frame: #aaaaaa
    fullscreen: show
    progress: -1
    stack_tag:
    id: 2
    actions: {}
    script: (null)
}

with both 1.4.1 and master. But I'll test with master to see whether it is already fixed.

[mithodin]

Problem remains in master.

11:30 is okay, 12:00 and up are broken.

[tsipinakis]

Could you post the dunstrc you're using?

Mind the idle_threshold value, if that's enabled and dunst detects you're idle the timeout timer will restart.

[mithodin]

Oh, that might be the reason. I have copied the default configuration and the idle_timeout was set to 120. Will test again.

[mithodin]

Nope, even with idle_threshold = 0, no timeout >= 11.9 minutes works.

[mithodin]

Got it down to the milisecond: -t 709821 works, -t 709822 does not.

[tsipinakis]

I can't reproduce this locally from the tests I ran (another one is running right now - with the cycle time of this it's hard to pinpoint).

So, let's get to debugging:

1. Can you paste the dunstrc you're using if it differs from the default? (Keep in mind the settings hardcoded in dunst can be slightly different from the ones in the default dunstrc)

2. Please build and reproduce the issue with this branch and post the output - might help narrow it down. (run with -verbosity debug -print)

---

OT: @bebehei What would you say of merging that branch to master and adding more such calls, we could use a much more verbose debug output.

[mithodin]

I have been able to capture output when the bug was triggered.
dunst.log
and here is my dunstrc:
dunstrc.txt

[mithodin]

Oh, and it is somehow still triggered by idling. If I am reasonably active during the timeout, it does not trigger.

[tsipinakis]

Were these notifications shown the entire time? Logs show the 14 minute and 15 minute ones were held in the waiting queue.

The timer doesn't tick while the notifications are hidden.
For reference the 14 minute notification was sent at 171629176700, started being displayed but when the 15 minute one arrived they were both pushed into waiting as dunst ran out of notification slots.

You killed dunst at 172512187242, and at about the middle of the log file there's:

DEBUG: queues::queues_update: waiting -> display
DEBUG: queues::queues_update: Evaluating : id: 6 summary: C: 14 minute timeout
DEBUG: queues::queues_update: Start time=172229128905
DEBUG: queues::queues_update: Evaluating : id: 7 summary: C: 15 minute timeout
DEBUG: queues::queues_update: Start time=172229128925

Meaning they had ~5 more minutes till they time out.

[mithodin]

okay, that must be the reason then. I guess you can close this issue, I will report back if I end up triggering it again at some point.

[bebehei]

OT: @bebehei What would you say of merging that branch to master and adding more such calls, we could use a much more verbose debug output.

I think those calls cover mainly the stuff, what a debugger should be used for. Using such verbose "comments" blow up the code, amount of logs used and cover only a small use case. I'm not that convinced to be a good idea.

[tsipinakis]

I think those calls cover mainly the stuff, what a debugger should be used for.

True, this will mostly be useful to address the case of remote debugging where neither of us can reproduce the issue, such as this or #620. And as you mentioned can be useful as "comments" as well.

If you're worried about performance we could compile these out in release builds.