Expose setting the flatpak update schedule

[marksvc]

Thank you for your great work in designing and providing Universal Blue!

Automatic updates to flatpak runtimes occasionally result in crashes later that day to applications, like LibreOffice Writer and Firefox[1]. Because of this, I had made some modifications to flatpak-system-update.timer and flatpak-user-update.timer to stop their timer from running every day, and to instead run at boot/login, and every 60 days there-after. Then it will only crash applications if a computer really hasn't been rebooted for a couple months.

Recent changes to Universal Blue seem to have moved away from flatpak-system-update.timer and flatpak-user-update.timer. Possibly to uupd.timer. But I haven't entirely worked out how to change the flatpak user and flatpak system update cadence.

Can you please expose a capability and/or provide documentation, describing how to change the flatpak update frequency? [2]

I understand from Universal Blue blogs that frequent reboots are the style of some of the developers. Please note that not doing weekly reboots isn't necessarily the cause of the problem described above. I expect these particular crashes to happen even if the machine were rebooted the previous day. So users who frequently reboot would also benefit from the capability to modify their flatpak update schedule if this adequately bothered them.

Thank you again for all of your amazing work in providing Universal Blue!

[1] I know this isn't supposed to happen. But that hasn't kept LibreOffice from crashing after a runtime update that morning :-)
[2] uupd.timer could be adjusted to run at boot and then not again for 60 days, but I still want the system image updates to be fetched in the background. It's the flatpak updating that I want to delay.

[hanthor]

You can follow the instructions here

https://github.com/ublue-os/uupd

And disable the flatpak module of uupd in /etc/uupd/config.json.

Then you can enable the old timer like how you had it before?

You are reducing your odds of a regression I guess by only forcing update every 60 days, but only marginally

[hanthor]

I have a stupid idea, have a script that updates flatpaks daily, but only to 4 day old updates (assuming bad updates might not hang around for 3+ days). Here's a bash script I asked AI to generate, seems like it might work:

#!/bin/bash

DELAY_DAYS=4
THRESHOLD_SECONDS=$((DELAY_DAYS * 86400))
CURRENT_TIME=$(date +%s)

mapfile -t apps < <(flatpak remote-ls --updates --columns=application,remote)

for line in "${apps[@]}"; do
    read -r app_id remote <<< "$line"
    echo "Checking $app_id..."

    # Get the commit history (log) from the remote
    # We look at the last 10 commits to find a 'safe' one
    mapfile -t history < <(flatpak remote-info --log "$remote" "$app_id" | grep -E "Commit:|Date:" | paste - -)

    safe_commit=""

    for entry in "${history[@]}"; do
        # Extract Commit hash and Date
        commit_hash=$(echo "$entry" | awk '{print $2}')
        date_str=$(echo "$entry" | cut -d: -f3- | xargs)
        
        commit_time=$(date -d "$date_str" +%s)
        age=$((CURRENT_TIME - commit_time))

        if [ "$age" -ge "$THRESHOLD_SECONDS" ]; then
            safe_commit="$commit_hash"
            break # This is the newest commit that satisfies our 4-day rule
        fi
    done

    if [ -n "$safe_commit" ]; then
        echo "--> Found safe commit: $safe_commit (Updating...)"
        flatpak update -y --commit="$safe_commit" "$app_id"
    else
        echo "--> No commit found old enough to be 'safe' yet."
    fi
done

[marksvc]

Thanks for that, @hanthor! I had seen the uupd page, but I am concerned that disabling part of uupd and providing my own flatpak update service units may not survive very long as a set-it-and-forget-it solution. I had naively assumed overriding the flatpak-system-update.timer and flatpak-user-update.timer files would be lasting, but between designing a solution and getting around to testing it in a virtual machine, Universal Blue already moved away to a new update system :-).

So I realize I need more of a Universal Blue-level configuration setting rather than just manually going in and overriding an existing implementation.

And maybe I can't expect a set-it-and-forget-it solution right now until some more Universal Blue systems solidify. For now, it looks like maybe I should be looking at further capability of /etc/uupd/config.json.

Thank you for suggesting this script. I'm intrigued by applying flatpak updates that are not brand new.

[castrojo]

Is there a bug for the runtime crash thing somewhere?

[marksvc]

Hello @castrojo,

Thank you for asking. I did some more investigation today of the times and logs of the crash events. Although I had been seeing a correlation between runtime updates and crashes of LibreOffice and Thunderbird before, I observed that after I had reduced the frequency of flatpak updates, the crashes continued to occur even without them. And so I am doubting now that the flatpak updates are the cause of the crashes.

This is both good and bad news :)

The error messages from LibreOffice Writer and Thunderbird have text such as the following. I plan to diagnose it a bit more before reporting a separate issue.

Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.

Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /run/host/share/icons/Adwaita/scalable/status/image-missing.svg: Unrecognized image file format (gdk-pixbuf-error-quark, 3)