Dunst: Dunst notifications displayed on lockscreen (betterlockscreen, xtrlock)

Created on 27 Mar 2020 · 5Comments · Source: dunst-project/dunst

Installation info

Version: Dunst - A customizable and lightweight notification-daemon 1.4.1 (2019-07-03)
Install type: dunst from official Arch repositories
Distro and version: Arch Linux

Original issue: https://github.com/pavanjadhaw/betterlockscreen/issues/160

Asking here since the issue occurs both with betterlockscreen and xtrlock.

I'm using Arch Linux with the following packages:

My issue is that dunst notifications still appear on lockscreen.

I've run systemctl enable betterlockscreen@$USER to enable the user service.

If I understand correctly, since the systemd user service is enabled, betterlockscreen does the following before locking, and this after unlocking.

I tried to use a lockscreen script replicating these commands instead of using the regular betterlockscreen -l -t "" command as a workaround (since the dunst notifications were still displayed), but unfortunately it doesn't make any difference.

lockscreen.sh

#!/bin/bash

pkill -u "$USER" -USR1 dunst
betterlockscreen -l -t ""
pkill -u "$USER" -USR2 dunst

_Note: I also tried with killall -SIGUSR1 dunst and killall -SIGUSR2 dunst as suggested on the Arch Wiki._

and here's how it's triggered by xidlehook^AUR:

~/.xinitrc

#!/bin/bash

dunst &
xset s on &
xset s 600 &
xidlehook \
--not-when-fullscreen \
--not-when-audio \
--timer 300 '~/scripts/lockscreen.sh' '' &

So basically, the screen locks after 5 minutes and turns off after another extra 5 minutes. This works perfectly fine, my only issue is that dunst notifications are still displayed on the lockscreen.

It's quite difficult to reproduce.

Thanks in advance.

Edit: I'm also using picom with the following in picom.conf:

picom.conf

backend = "glx";

glx-no-stencil = true;
glx-copy-from-front = false;

shadow = false;
shadow-radius = 5;
shadow-offset-x = -5;
shadow-offset-y = -5;
shadow-opacity = 1;

shadow-ignore-shaped = false;

inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;

detect-client-opacity = true;

blur-background = false;
blur-background-frame = false;
blur-background-fixed = false;

fading = true;
fade-delta = 4;
fade-in-step = 0.03;
fade-out-step = 0.03;

fade-exclude = [ ];

mark-wmwin-focused = true;
mark-ovredir-focused = true;

use-ewmh-active-win = true;
detect-rounded-corners = true;
refresh-rate = 0;
vsync = true;
dbe = false;
unredir-if-possible = false;

focus-exclude = [ ];

detect-transient = true;
detect-client-leader = true;

wintypes:
{
    tooltip =
    {
        # fade: Fade the particular type of windows.
        fade = true;
        # shadow: Give those windows shadow
        shadow = false;
        # opacity: Default opacity for the type of windows.
        opacity = 1;
        # focus: Whether to always consider windows of this type focused.
        focus = true;
    };
    popup_menu = { opacity = 1; };
};

xrender-sync-fence = true;

Bug graphics help wanted

Source

ghost

All 5 comments

Well, I'm a maintainer of this and I even have the same problem. :see_no_evil: I'm using i3lock as lockscreen and I'm using compton as a compositing manager.

In our research, we found out, that, it's linked to the compositor of your system, which introduces some weird race conditions or so.... :confused: Ref: i3/i3lock#204 #553

bebehei on 27 Mar 2020

👀1 👍1

Other than the compositor issue the pause/unpause solution mentioned above is my workaround, and it works perfectly in my case.
For why it doesn't work here, I suspect this is a bug in betterscreenlock from a quick read-through of the script it calls i3lock without the --nofork so i3lock forks immediately on launch which makes it run the unpause command.

tsipinakis on 27 Mar 2020

In our research, we found out, that, it's linked to the compositor of your system,

Thanks for the info, I'll disable picom for now and see if that solves the issue.

Other than the compositor issue the pause/unpause solution mentioned above is my workaround, and it works perfectly in my case.
For why it doesn't work here, I suspect this is a bug in betterscreenlock from a quick read-through of the script it calls i3lock without the --nofork so i3lock forks immediately on launch which makes it run the unpause command.

As I said, the issue also occurs with xtrlock ( which doesn't use i3lock if I'm not mistaken), invoked with the following script:

lockscreen.sh :

#!/bin/bash

pkill -u "$USER" -USR1 dunst       # or killall -SIGUSR1 dunst  
xtrlock -b
pkill -u "$USER" -USR2 dunst       # or killall -SIGUSR2 dunst

ghost on 27 Mar 2020

So I disabled picom and I can confirm that not a single notification appeared on my lockscreen (currently using betterlockscreen) in the last ~15 hours. They were all displayed after I unlocked.

ghost on 28 Mar 2020

I can confirm I have the same issue running picom. Disabling it solves the problem as well, but unfortunately I need it. Perhaps we should take this to picom?