A package update notifier?

johnraff · 2023-04-29 07:46:31

Anyway, the hanging of apt updates in bl-welcome is fixed if the command run by bl-notify-broadcast-new (soon to be renamed to bl-run-broadcast) is forked away with disown and setting job control: https://forums.bunsenlabs.org/viewtopic … 832#p97832
So the line that works OK is:

runuser -u "${displays[$d]}" -- bash -c "set -m; DISPLAY=:0 $(printf '%q ' "$cmd" "$@" ) >/dev/null 2>&1 & disown; set +m;"

More and more complicated, but having come this far, let's get it done. The question of whether to actually use the thing can come later.

sleekmason · 2023-04-29 13:17:37

I'm starting to wonder if this is going to be worth all the trouble, compared with just offering to install package-update-indicator in bl-welcome?

Yeah probably. But for myself, I'm learning a bunch while going through the process. Thanks for the link on forking btw.

Just setting up the systemd user timer itself is gold, let alone the rest of this.

More and more complicated, but having come this far, let's get it done.

Eagerly awaiting whatever develops:) Wish I had more knowledge to help.

johnraff · 2023-04-30 11:20:21

Made some changes:
https://sourceforge.net/projects/bunsen … t4_all.deb

I think I've fixed most of the glitches:
*) If a new trigger comes in, and the icon is still being displayed because user hasn't got round to upgrading (or upgraded in a separate terminal), the icon is killed and a fresh one put up with the latest info - or not, if there are no longer any upgrades.
*) Timer + apt triggers: 10min after login + every 24hrs + whenever apt does an update.
*) Also (is supposed to) run just after the first package install (not yet confirmed).
*) If there's no systemd it should still work without the timer - just the apt triggers.
*) bl-run-broadcast should no longer make apt hang when doing updates from bl-welcome.
*) Man pages for bl-update-checker and bl-run-broadcast.

Latest code here: https://github.com/BunsenLabs/bunsen-apt-update-checker

Please check it out if you have a moment.

sleekmason · 2023-04-30 15:24:17

Awesome.

Couple of issues. One new..

- The additional version keeps the available count at 1, and places an icon. This in turn keeps the icon active when it probably shouldn't be?

Available upgrades:
Listing... Done
firmware-nvidia-gsp/testing 525.105.17-1 amd64 [upgradable from: 525.89.02-1]

N: There is 1 additional version. Please use the '-a' switch to see it

- and, While the icon is present, dpkg hangs on upgrade when using another terminal. Closing the icon completed the upgrade. (double checked to make sure old version of bl-run-broadcast wasn't present.) *edit - Had a copy in ~/bin as well, if that made any difference. Still the new version.

Other notes..
Just curious as to why the change to /sbin for bl-run-broadcast?

Last edited by sleekmason (2023-04-30 15:30:45)

johnraff · 2023-05-01 00:21:44

Thanks for checking.

sleekmason wrote:

The additional version keeps the available count at 1, and places an icon. This in turn keeps the icon active when it probably shouldn't be?
Available upgrades:
Listing... Done
firmware-nvidia-gsp/testing 525.105.17-1 amd64 [upgradable from: 525.89.02-1]

N: There is 1 additional version. Please use the '-a' switch to see it

I didn't see this, but it makes sense if that "additional version" line appears it will bump the upgrade count by 1. But if the package is upgraded, the "additional version" line should be gone too, no? This is hard to test unfortunately. I guess we just have to wait for the next upgrade to arrive where a package has more than one version available...

I see from the deb security mailing list that ffmpeg has had an upgrade so expect that to show up on the system some time today. It might help with debugging...

While the icon is present, dpkg hangs on upgrade when using another terminal. Closing the icon completed the upgrade.

That's disappointing - I thought I had fixed that issue. Are you sure the bl-run-broadcast in ~/bin is the latest version? Could you rename it and see if the issue persists?

Just curious as to why the change to /sbin for bl-run-broadcast?

That's the correct place for system maintainer utilities. bl-run-broadcast only runs as root so it seemed appropriate.

sleekmason · 2023-05-01 02:07:19

I was in luck and had a build from a couple days ago. Zero problems on a new install for dpkg!

Not only did I have an extra file in ~/bin, but I believe I used nala last time as well. I reproduced it cleanly this time and all went well.

The additional version issue probably would only apply to unused firmware then? I suppose the easy answer is for folks to uninstall it . .

I kept it installed this time and so will receive the same messages again if that is of any help.

Ah, then that answers what the difference was regarding bl-run-broadcast. Good to know.

Last edited by sleekmason (2023-05-01 02:08:19)

johnraff · 2023-05-01 04:20:29

sleekmason wrote:

Zero problems on a new install for dpkg!

So that 'hanging while the icon is being displayed' issue has gone away? Great relief if so!

Not only did I have an extra file in ~/bin...

Any executable you have in ~/bin will overrule whatever a package has installed in /usr/bin or /usr/sbin

but I believe I used nala last time as well.

Hopefully, it shouldn't matter if you run nala or aptitude or whatever. The only remaining annoyance I'm aware of is that if the icon is triggered and user then leaves it open and instead of opening the terminal from the icon menu they do some apt operations elsewhere, the icon won't know about it and will stay open - unless the script gets triggered by another apt update. In that case it will close the old icon, see there are no more upgrades and not open a new one. So an unwanted icon might hang about for a while... depending. (Of course the user can always close it manually.)

The additional version issue probably would only apply to unused firmware then?

I think it's when there are versions of a package available both from Debian security and regular Debian stable - cases like that, not specifically firmware. Once the package has been upgraded I think the "additional version" message will disappear too.

I'm still waiting for ffmpeg to arrive. I could trigger the notifier script by doing an apt update manually but I want to see if the system can handle it by itself. package-update-indicator isn't showing anything either atm.

EDIT
On my Boron VM another upgrade appeared. Both our app and package-update-indicator put up notifications. Instead of opening the terminal from the icon menu, I left it as it was and ran bl-welcome. At the apt update page it ran OK (no hang) and the BL icon closed and re-opened, showing the updates were still available. When bl-welcome went on to the apt upgrade phase the notification icon was closed. Perfect!

Last edited by johnraff (2023-05-01 05:09:23)

sleekmason · 2023-05-03 22:52:07

Still testing and adjusting further for my own use, but feeling pretty dang good about how this turned out. Nice work @johnraff. It's a cool addition.

johnraff · 2023-05-05 08:53:36

It's been installed for a week or so now, and seems to be working pretty well.

I just want to look at the bit where it takes the PID out of a file to kill a previously-running instance, if any. Need to make quite sure no innocent process gets killed by mistake.

Otherwise it looks good - no continually running process at all, unless you count the systemd timer, so lighter in system resources than package-update-indicator, and a much smaller download.

---
@sleekmason, if you want to add eg an "Upgrade" menu item, you should be able to add another function similar to show-upgrades(), add it to the export list and add a menu item that calls 'bash -c <newfunction>'. Haven't tested but that ought to work for any menu item. If you don't want to close the icon after running the function then you won't need the PIPE exit-handling stuff inside it.

sleekmason · 2023-05-05 13:44:49

johnraff wrote:

It's been installed for a week or so now, and seems to be working pretty well.
I just want to look at the bit where it takes the PID out of a file to kill a previously-running instance, if any. Need to make quite sure no innocent process gets killed by mistake.
Otherwise it looks good - no continually running process at all, unless you count the systemd timer, so lighter in system resources than package-update-indicator, and a much smaller download.
---
@sleekmason, if you want to add eg an "Upgrade" menu item, you should be able to add another function similar to show-upgrades(), add it to the export list and add a menu item that calls 'bash -c <newfunction>'. Haven't tested but that ought to work for any menu item. If you don't want to close the icon after running the function then you won't need the PIPE exit-handling stuff inside it.

So far so good! What I wound up doing was working off the idea of a spot check version activated through a tint2 button.

For this version, I removed the timer and added an 'export' item to handle changing the icon on the fly using the same PIPE exit function to close and reopen the icon with the new color change.

I then also added an upgrade portion directly to the terminal code to upgrade, using nala if available, or apt if not.

Basically, you get a left-click check for updates, and a right-click menu with the three options of 'Available Upgrades', 'Change icon color' and 'Quit'

I then also made an installable .deb with the system.d user timer as well using the excellent template you provided. I'm guessing no one will ever know the amount of work that goes into one, lol. I do now. I'm cheating by using a super cool 'Unpack' script I found. (yes yours). It has been very enlightening. It is certainly pushing me towards creating a repo and learning how to properly build a .deb package.

Anyway, in the installable version, I just made conditions for 'if not' in Lilidog, but I need to do more/better there. Everything works but is a bit clunky.

The spot check version pretty much 'just works' but the installable timer version has a couple of minor issues I'll need to iron out. I'm using the second line option in the run-broadcast script, as the first line was showing 'diamond' artifacts during the upgrade portion. ( I think. . . This was trial and error for me with monkeys howling in the background.)

*edit - here is the spot check script and color change script for any who might want to adjust it for their own uses or just see easy ways to make it better.)

#!/bin/bash

# This script will place an icon in the system tray for upgrade 
# notifications on button click, with an option to upgrade and 
# an option to change the icon color throught the associated
# ~/.config/tint2/scripts/tint2-apt-update-check-color.
# Nala is optional.  requires yad.

on_exit() {
    echo "quit" >&3
    rm -f "${PIPE}"
    rm -rf "${PIPE%/*}"
    exec 3>&-
    exec 4>&-
    :>"$lockfile" # lockfile only holds pid while script is running
}

# If there is a previous icon still not closed, kill and replace it if still needed
lockfile='/tmp/tint2-apt-update-check-lock'
exec 4<>"$lockfile"
tries=3 # give up if cannot get lock
(( i=1 ))
until flock --verbose -n 4
do
    (( i > tries )) && { echo "${0}: failed to kill old process" >&2 ; exit 1;}
    echo "${0}: another instance is running, now killing it" >&2
    oldpid=$(<"$lockfile")
    kill "$oldpid"
    tail -f /dev/null --pid="$oldpid" # https://forums.bunsenlabs.org/viewtopic.php?pid=114592#p114592
    (( i++ )) # one repetition should be enough in fact
done

printf '%s' "$$" > "$lockfile" # using lockfile to store pid

trap on_exit EXIT

 
upgradecolor=$(< "$HOME/.config/tint2/executors/color.txt")

show-upgrades(){
    trap on_exit EXIT
    [[ -p "$PIPE" ]] || { echo "${0}: there is no fifo $PIPE" >&2 ; exit 1;}
    exec 3<> "$PIPE"
    if [ -x /usr/bin/nala ]; then
    x-terminal-emulator -T 'Available Package Upgrades' -e sh -c 'printf "%s\n" "Available upgrades:"; \
    apt list --upgradeable; printf "\n%s\n"  "Held packages:"; \
    apt-mark showhold;  echo "... Done"; echo ""; echo \
    "Please enter your password to continue to upgrade your system."; echo \
    "Or close this window to quit now.  < ctrl +c >"; echo ""; \
    sudo nala upgrade; bash;'
    else
    x-terminal-emulator -T 'Available Package Upgrades' -e sh -c 'printf "%s\n" "Available upgrades:"; \
    apt list --upgradeable; printf "\n%s\n"  "Held packages:"; \
    apt-mark showhold;  echo "... Done"; echo ""; echo \
    "Please enter your password to continue to upgrade your system."; echo \
    "Or close this window to quit now.  < ctrl +c >"; echo ""; \
    sudo apt upgrade; bash;'
    fi
    exit
}

icon-color-change(){
    trap on_exit EXIT
    [[ -p "$PIPE" ]] || { echo "${0}: there is no fifo $PIPE" >&2 ; exit 1;}
    exec 3<> "$PIPE"
    "tint2-apt-update-check-color"
    "tint2-apt-update-check"
    exit
}

dir=$(mktemp --tmpdir --directory "${0##*/}".XXXXXXXX) || { echo "${0}: could not make temp dir" >&2 ; exit 1;}
PIPE="${dir}/yadpipe"
mkfifo "$PIPE" || { echo "${0}: could not make fifo $PIPE" >&2 ; exit 1;}
exec 3<> "$PIPE"

export PIPE
export -f on_exit
export -f show-upgrades
export -f icon-color-change

num_upgrades=$(( $( apt list --upgradable 2>/dev/null | wc -l ) - $( apt-mark showhold | wc -l ) -1 ))
if (( num_upgrades == 0 )); then
notify-send  -t 10000 --urgency low "$num_upgrades Upgrade(s) Currently Available"
fi
if (( num_upgrades > 0 )); then
    notify-send  -t 10000 --urgency low "$num_upgrades Upgrade(s) Currently Available"
    yad --notification --listen --image="$HOME/.config/tint2/executors/icons/update/$upgradecolor" \
    --text="Package Upgrades - Right-Click For Options" \
    --menu="Show Available Upgrades!bash -c show-upgrades!software-update-available|Change Icon Color!bash -c icon-color-change!applications-graphics|Quit!quit!application-exit" \
    --command="notify-send  -t 10000 --urgency low '$num_upgrades Upgrade(s) Currently Available'" <&3
fi

And the color change script. Will require some path changes and some groovy icons to work;)

#!/bin/bash
# tint2 apt notifier color options.
 
FILE="$HOME/.config/tint2/executors/color.txt"
noti=$(yad --width 330 --borders=8 --entry --title "Notifier Icon Color" --center --window-icon=applications-graphics \
    --image="/usr/share/icons/hicolor/24x24/apps/org.xfce.settings.color.png" \
    --button="gtk-ok:0" \
    "Green" "Blue" "Magenta" "Yellow" "Orange" "Plain" "Red")

case $noti in
  Green)
     sed -i 's/^update.*/update-green.png/g' "$FILE"
;;
  Blue)
     sed -i 's/^update.*/update-blue.png/g' "$FILE"
;;
  Magenta)
     sed -i 's/^update.*/update-magenta.png/g' "$FILE"
;;
  Yellow)
     sed -i 's/^update.*/update-yellow.png/g' "$FILE"
;;
  Orange)
     sed -i 's/^update.*/update-orange.png/g' "$FILE"
;;
  Plain)
     sed -i 's/^update.*/update-plain.png/g' "$FILE"
;;
   Red)
     sed -i 's/^update.*/update-red.png/g' "$FILE"
;;
        *) exit 1 ;;
    esac

Last edited by sleekmason (2023-05-05 13:54:16)

johnraff · 2023-05-06 01:27:46

^that's all very interesting. (You can drop the --verbose option for flock once debugging is finished.)

But I think for now, for BL I'll stop development as soon as the "protect innocent processes" bit is done, and upload the package to the regular repos as it is. Also add an option to install it via bl-welcome (not include it in the default install list).

Anyway, I'm finding it useful enough that I can uninstall package-update-indicator.

johnraff · 2023-05-07 06:53:28

johnraff wrote:

the "protect innocent processes" bit

I made this function:

# check if pid belongs to an instance of this script, even if run via a symlink
# not perfect but should cover many cases, and error out otherwise
check_pid() {
    local pid=$1
    local script path cmd
    kill -s 0 "$pid" || { echo "${0}: PID ${pid} is not running" >&2 ; exit 1;}
    script=$( readlink -e "$0" ) || { echo "${0}: failed to find path to this script" >&2 ; exit 1;}
    mapfile -d '' -t cmd < "/proc/${pid}/cmdline"
    path=${cmd[-1]} # this script takes no arguments, so it is the last part of the command line
    if [[ $path = /* ]] # absolute path
    then
        path=$(readlink -e "$path")
    else
        path=$( readlink -e /proc/"${pid}"/cwd/"$path" ) # assume path is relative to working directory
    fi
    [[ "$path" = "$script" ]] || { echo "${0}: PID ${pid} seems to belong to a different process: ${path}" >&2 ; exit 1;}
}

The current idea is that a running script writes its PID in the lockfile /tmp/bl-apt-update-check-lock, and deletes the number, but not the file, when it exits. flock is used to make sure there isn't another instance already running, but if there is then the script uses the PID in the lockfile to kill it, so the new instance can take over.

check_pid() is to make sure that the file hasn't got corrupted, or maliciously edited, so that the PID might refer to some other process. There's a directory /proc/<pid> for each running process, and /proc/<pid>/cmdline has the whole command line, while /proc/<pid>/cwd is the working directory. Then applying 'readlink -e' to the filepaths (see man readlink) we can unpick any symlinks and check the PID's process really belongs to an instance of the current running script.

check_pid is run just before killing the PID: https://github.com/BunsenLabs/bunsen-ap … -check#L75

It may not be perfect but I think if it fails it will fail-safe, ie report a problem and exit even if it's OK. It coped OK with an update-notifier called via a symlink. The worst result is the user having to close an icon manually, but I think that should be very seldom. Better than killing some quite unrelated blame-free process.

Last edited by johnraff (2023-05-07 07:38:35)

johnraff · 2023-05-07 07:54:49

bunsen-apt-update-checker 12.0-1
is in the Boron repository.

sleekmason · 2023-05-07 18:29:05

johnraff wrote:

the "protect innocent processes" bit

I made this function:

# check if pid belongs to an instance of this script, even if run via a symlink
# not perfect but should cover many cases, and error out otherwise
check_pid() {
    local pid=$1
    local script path cmd
    kill -s 0 "$pid" || { echo "${0}: PID ${pid} is not running" >&2 ; exit 1;}
    script=$( readlink -e "$0" ) || { echo "${0}: failed to find path to this script" >&2 ; exit 1;}
    mapfile -d '' -t cmd < "/proc/${pid}/cmdline"
    path=${cmd[-1]} # this script takes no arguments, so it is the last part of the command line
    if [[ $path = /* ]] # absolute path
    then
        path=$(readlink -e "$path")
    else
        path=$( readlink -e /proc/"${pid}"/cwd/"$path" ) # assume path is relative to working directory
    fi
    [[ "$path" = "$script" ]] || { echo "${0}: PID ${pid} seems to belong to a different process: ${path}" >&2 ; exit 1;}
}

I added the code and everything works here. Now I need to study this.)

bunsen-apt-update-checker 12.0-1
is in the Boron repository.

Awesome!

Last edited by sleekmason (2023-05-07 18:29:30)

or1o9 · 2023-05-09 16:48:01

Discreet, neat, and tidy. Solid work team.

I might actually keep it.

or1o9 · 2023-05-28 09:21:08

Today I booted my "Boron" and after three hours and no sign from the update-notifier I decided to run an update in terminal to see if there were some. And it was, 33 actually. Should not the update-notifier have notified me about this?

It has happened before too, that when I check there are updates, but no notification. To it ´s defense it has worked a couple of times too, but I think I got the notification after much more than 10 minutes. Wish I had paid more exact attention to this now.

Is it working as it should for you? Or is it just glitching for me?

rbh · 2023-05-28 15:44:15

orionH wrote:

is it just glitching for me?

For me too. Seems like I need to run an manual update before bl-notify-broadcast, can throw up the yad-window and the icon appears.
Next reboot, the notification appear after 10½ min.
The notification has worked, but I.m noit sure if it has worked all times or if it was the testpackage that worked...

Will keep an eye on it.

jr2 · 2023-05-30 16:57:42

Feedback like this is valuable!

You can't expect instant notification as soon as an update arrives in the repos, but I don't think it should take more than 24 hrs, usually less. I don't think updates will be missed completely.

Various things, like a manual apt update, will trigger it, but I think the notification arrives eventually.

Just try ignoring it for a while. I have found it catches up eventually.

or1o9 · 2023-06-10 11:37:45

jr2 wrote:

Just try ignoring it for s while. I have found it catches up eventually.

Yes, it did catch up finally, after ca 10 days and 20 - 25 hours of uptime without notifications, it notified me that there were 14 of them today.

sleekmason · 2023-06-10 15:08:09

From what I can tell, it is looking like the systemd timer doesn't get enabled on install of the program. The script runs once on install, but no further checks occur until the systemd timer gets enabled through a terminal or after boot. The timer is being enabled on boot and works correctly thereafter.

I suppose the question is how to enable the systemctl timer on initial script run? Maybe something else in the postinst file of the .deb?

The other timer settings are currently set for 10 minutes after startup, and once per day thereafter. I've switched mine to 2min for startup and 6h thereafter.

Last edited by sleekmason (2023-06-10 15:11:12)

#41 2023-04-29 07:46:31

Re: A package update notifier?

#42 2023-04-29 13:17:37

Re: A package update notifier?

#43 2023-04-30 11:20:21

Re: A package update notifier?

#44 2023-04-30 15:24:17

Re: A package update notifier?

#45 2023-05-01 00:21:44

Re: A package update notifier?

#46 2023-05-01 02:07:19

Re: A package update notifier?

#47 2023-05-01 04:20:29

Re: A package update notifier?

#48 2023-05-03 22:52:07

Re: A package update notifier?

#49 2023-05-05 08:53:36

Re: A package update notifier?

#50 2023-05-05 13:44:49

Re: A package update notifier?

#51 2023-05-06 01:27:46

Re: A package update notifier?

#52 2023-05-07 06:53:28

Re: A package update notifier?

#53 2023-05-07 07:54:49

Re: A package update notifier?

#54 2023-05-07 18:29:05

Re: A package update notifier?

#55 2023-05-09 16:48:01

Re: A package update notifier?

#56 2023-05-28 09:21:08

Re: A package update notifier?

#57 2023-05-28 15:44:15

Re: A package update notifier?

#58 2023-05-30 16:57:42

Re: A package update notifier?

#59 2023-06-10 11:37:45

Re: A package update notifier?

#60 2023-06-10 15:08:09

Re: A package update notifier?

Board footer