Notification actions are broken

[PhrozenByte]

I'm trying to create an "immortal" notification that doesn't permanently disappear when being clicked. I thus want to create a notification whose default action does no more than re-creating the exact same notification. This allows me to add more actions with actual functionality later (but we can ignore this for now).

Here's a working minimal script for Bash 4.4 (note: I'm working with #3 here):

#!/bin/bash
NOTIFICATION_ID="$(mktemp -u)"

notification_send() {
    ./src/notify-send.sh --replace-file="$NOTIFICATION_ID" --default-action="kill -USR1 $$" "Test"
}

trap notification_send USR1
notification_send

while :; do
    sleep 1
done

Before starting an infinite loop the script first registers a trap on the SIGUSR1 signal and then calls the notification_send function to create a notification with the default action calling kill -USR1 $$ to trigger the trap. The trap itself also just calls the notification_send function to re-create the notification.

This should work indefinitely: The user clicks on the notification, the notification sends SIGUSR1 to the script, the script re-creates the notification, the user clicks on the new notification, the new notification sends SIGUSR1 to the script, the script re-creates the notification, the user clicks on the new notification, and so on…

One can easily verify that indefinitely re-creating the notification works just fine:

$ for i in $(seq 1 5); do sleep $i; kill -USR1 $PID; done

However, when clicking the notification (i.e. sending the SIGUSR1 signal using the action handler) it only works once: The original notification disappears and the re-created notification is shown, but clicking on that re-created notification breaks the cycle and just nothing happens.

./test.sh
PID=10339
+ ./src/notify-send.sh --print-id --default-action=kill -USR1 10339 Test
Warning: The notification service on your device doesn't support
         hyperlinks in it's body text. So they will be filtered out.
Warning: The notification service on your device doesn't support
         images in it's body text. So they will be filtered out.

# click on the notification

+ ./src/notify-send.sh --replace=228 --default-action=kill -USR1 10339 Test
Warning: The notification service on your device doesn't support
         hyperlinks in it's body text. So they will be filtered out.
Warning: The notification service on your device doesn't support
         images in it's body text. So they will be filtered out.

# terminate with Ctrl+C
^C

When killing the script with Ctrl+c there are two dangling notify-action.sh processes left:

$ ps aux | grep notify
daniel   10435  0.0  0.0   4636  1856 ?        Ss   22:22   0:00 /bin/sh /home/daniel/Projekte/GitHub/notify-send.sh/src/notify-action.sh 228 default kill -USR1 10339
daniel   10447  0.0  0.0   4636   132 ?        S    22:22   0:00 /bin/sh /home/daniel/Projekte/GitHub/notify-send.sh/src/notify-action.sh 228 default kill -USR1 10339
daniel   10875  0.0  0.0  14784  1108 pts/2    S+   22:25   0:00 grep --exclude-dir .git notify

Enabling debug mode unfortunately doesn't bring up anything useful for me.

Any ideas? Thanks!

[M3TIOR]

The dangling processes were something I had a lot of trouble curing on my own system. I'm ashamed to see them return but not surprised.

Before I stopped working on the project, I was looking into POSIX Job IDs, which looked to be more reliable at removing children (and orphans) from a process tree than tracking the children in PID files. But I don't think I ever got them to work properly.

This is part of the reason I was trying to add unit tests to the project, so I could not only add regression prevention, but also iron out any weird behaviors that I hadn't previously anticipated. Never found a good shell unittest implementation though and I didn't have the energy at the time to make one.

Now that I've stared at the code for a hot second, I'm pretty sure the issue is going to be in the notification ID renegotiation. When the original notification gets deleted, and a new one is generated to replace it, there's an ID handshake that's probably poorly written. That's why the --replace-file option exists, it has to store the old notification ID so the new one can take it's place.

[PhrozenByte]

Unfortunately this one was/is kind of a breaking issue for me: it doesn't work with vlevit's notify-send.sh either, what was the reason why I looked for alternatives and found your fork. I often use notification actions as very basic GUI surrogate, thus I need notifications to "survive" a misguided click on the notification (which yields the default action in Gnome).

I opened the PRs in my evaluation phase of your fork, but got stuck on this issue. Therefore I proceeded searching for other alternatives and found https://github.com/bkw777/notice.sh (actually I found it earlier, but disregarded it due to its different command line option logic). bkw777's fork had some issues too, but after fixing them I got it working. Thus I'm using bkw777's fork right now. Maybe bkw777's fork gives some insights about what the issue might be?

Back to topic: I wanna make clear that the dangling processes itself aren't really an issue for me (okay, they kinda are because they accumulate over time, but not primarily). My issue is that the cycle of recreating notifications breaks after the first notification is clicked: even though the first click works as intended and another notification is created, a click on this second notification does nothing. My goal is that if the user clicks on the notification, it's recreated. If the user then clicks on that notification, yet another notification is recreated. Another click, another notification. And again, and again, and again…

Unfortunately I didn't dig deep enough into the code to say anything about what the issue might be. The issue is similar to vlevit's notify-send.sh and was fixed by bkw777 in his fork though.