[FitTrackee] Self-hosted outdoor activity tracker 🚴

[petrus]

Solved the problem, it’s ok now
A big thank you for your hard work

[Tho]

Nice!
So you may now want to delete the old .rustup folder by rm -R /var/www/fittrackee/.rustup.bkp

[ghose]

upgrade to 0.8.8 failed with same issue

redis.exceptions.ResponseError: DB index is out of range

[ghose]

Hi @Tho

I’ve been searching about redis issue in the logs and found this in stackoverflow

from logs

redis url parameter

REDIS_URL=redis://127.0.0.1:6379/16

(channel 16)

the problem in log file

redis.exceptions.ResponseError: DB index is out of range

from link

means that the channel index at the end of your connection string (3) exceeds the maximum value for your installation. Usually there are 16 channels, so without further information it is unclear what this maximum value might be for your particular version. However, assuming Redis is properly installed, you can be assured that the value of 0 will be within the correct index range.

please read complete answer with a link to source this issue

In my server

trying to «ping» the channel

root@ynh:~# redis-cli -n 0 -h localhost -c 'PING'
PONG
root@ynh:~# redis-cli -n 16 -h localhost -c 'PING'
root@ynh:~# redis-cli -n 3 -h localhost -c 'PING'
PONG
root@ynh:~# 

look that channel 16, channel from URL, does not answer («3» was just for testing)

So my question is if this channel is set from upstream and if it is some value you/we can change in our package or even myself in my server (as if I’m the only affected).

Thank you.

[Tho]

Yes indeed this is the issue. It’s not an upstream bug, but a packaging bug. As it arise after the merging of helpers2.1, I suspect that the new helper has an issue.
I didn’t find the time for now, but I will try to take a look asap

[ghose]

take your time, current version 0.8.6 works absolubtely fine

I’m glad you had already identified the root problem.

[Tho]

I think I’ve found the issue!

Could you please try to update to the testing branch?

sudo yunohost app upgrade fittrackee -u https://github.com/YunoHost-Apps/fittrackee_ynh/tree/testing --debug

Thanks!

[ghose]

thank you @Tho , it has failed though

log: https://paste.yunohost.org/raw/osojebekac

2024-09-18 04:21:32,370: ERROR - Could not upgrade fittrackee: An error occurred inside the app upgrade script : Variable $redis_db wasn't initialized when trying to replace __REDIS_DB__ in /var/www/fittrackee/.env

[Tho]

Okay, fixed. Could you try again?

[ghose]

this is the log file reported https://paste.yunohost.org/raw/qoqexutedo

it’s failed

[Tho]

Okay, this is the chicken and the egg issue

I explain: there was for some times an issue with the upgrade script where a new redis_db was created at every upgrade, without cleaning the old one. So I experienced on my installation too that a lot of redis_db were created, but not necessarily in use.

I tried on my installation the following script: it checks which database is used by your installed apps.

/!\ It has worked on my install but I don’t know if it’s the easiest way nor if it covers everything. Don’t forget to dubblecheck /!\

#!/bin/bash

# Function to check which Redis databases are used by YunoHost apps
check_used_redis_dbs() {
    used_dbs=()

    # Get the list of all installed YunoHost apps
    app_list=$(yunohost app list --output-as json | jq -r '.apps[].id')

    # Loop through all YunoHost apps and check their settings.yml files
    for app in $app_list; do
        settings_file="/etc/yunohost/apps/$app/settings.yml"

        # Check if the settings.yml file exists for the app
        if [ -f "$settings_file" ]; then
            # Use yq to parse redis_db from the YAML settings file, removing any surrounding quotes
            redis_db=$(yq '.redis_db' "$settings_file" | sed 's/^["'\'' ]*//;s/["'\'' ]*$//')

            # Check if redis_db is valid (not empty or null)
            if [ -n "$redis_db" ] && [ "$redis_db" != "null" ]; then
                echo "App $app is using Redis DB $redis_db"

                # Add the redis_db to the used_dbs array
                used_dbs+=("$redis_db")
            fi
        else
            echo "Settings file for app $app not found."
        fi
    done

    # Output the unique Redis databases that are being used
    if [ ${#used_dbs[@]} -gt 0 ]; then
        echo ""
        echo "The following Redis databases are in use:"
        # Sort and remove duplicates from the used_dbs array
        echo "${used_dbs[@]}" | tr ' ' '\n' | sort -u
    else
        echo "No Redis databases are in use."
    fi
}

# Start the Redis DB check
echo "Checking which Redis databases are used by YunoHost apps..."
check_used_redis_dbs
echo "Script finished."

It will report some apps and the db number.
The db 0 is not reported, but you have to keep it, it’s probably in use (Nextcloud, Immich,…)

Then you can flush the unused ones (so the ones between 1 and 15 that are not reported) by
redis-cli -n 1 FLUSHDB (change 1 by the number of the unused db that you want to drop).

And after this, you can try to upgrade FitTrackee again, it should work this time

[ghose]

thank you, I will try tomorrow morning

[ghose]

(sent you a DM)

root@ynh:/home/ghose# ./redis-db 
Checking which Redis databases are used by YunoHost apps...
No Redis databases are in use.
Script finished.

I hope this helps you to improve or debug install/upgrade script, but I don’t want to waste your time with a problem that only applies to my system (apparently nobody else reports about)

EDIT:

After direct conversation with Thomas now fittrackee is upgraded (0.8.8)

[petrus]

Hey!
I migrated my Yunohost install from a RPi 2B server to a PC server (Proxmox virtual machine for Yunohost).
The command line has been used to create a backup : yunohost backup create
Then it has been restored with the command line yunohost backup restore xxx

After some apps fails loading, I did a “single” app restore with yunohost backup restore xxx --app fittrackee
Same problem (not surprised)

Services are not starting
fittrackee
https://paste.yunohost.org/qefojayofu
fittrackee_workers
https://paste.yunohost.org/ibuyujused

Humm ! Not sure if a backup/restore is cool to migrate the app ?
I’ve tried a new install after the 1st failed restore, there was another error (but it can be another thread… https://paste.yunohost.org/raw/ezojikubup)

Thx for your help
and hard work !

[Tho]

Could you try to upgrade te app to latest version after restore?

[ghose]

FTR 0.8.9

thank you

From changelog, we have now a «Description» field which it is suposed to inherit privacy value of the activity (when sharing features were implemented) and «Notes» field would be private for the user. If I have understand it correctly (I’ve asked Sam in matrix room)

[petrus]

Hey!
I did a new backup (from the RPi, app is ok), then restore on PC.
Then after this, on the YNH update webpage :
FitTrackee (fittrackee) de 0.8.7~ynh1 à 0.8.9~ynh1
Failed update log : https://paste.yunohost.org/raw/ubajuhifuh

thx!

[Tho]

May I ask you to try the following upgrade over your restore?

yunohost app upgrade fittrackee -u https://github.com/YunoHost-Apps/fittrackee_ynh/tree/remove-venv-before-upgrade --debug

It should help upgrading after switching from architecture (from 32bit to 64bit in your case).

[petrus]

Thx.
Here is the log
https://paste.yunohost.org/raw/qikaxacuku

Humm, or it’s not a problem to make a fresh install… it can be long, but not as long as your debug ?

[Tho]

Yeah! One issue already fixed

Humm, or it’s not a problem to make a fresh install… it can be long, but not as long as your debug ?

I don’t understand what you mean haha, a fresh install works?

If you are still willing to try fix the actual issue, could you give me the output of ls -lah /etc/postgresql/?