Upgrade broke some apps, maybe we should discuss about the upgrade machanism?

Hello all !

I use yunohost as my daily tool to do all my things I wantto be accessible at work and at home.
One of this thing is keeping the acticles and tutorials I use daily with wallabag and shaarli.
Recently I upgraded (after doing some backups) my yunohost and its applications from 3.4 to 3.6 and while yunohost itself had no problem upgrading, a lot of my apps were unable to upgrade or are now broken.
Without my wallabag i’m naked and can’t work efficiently. So l’ll restore my backup to 3.4.

It seems that fail2ban encountered a problem while upgrading and then it created a chain reaction somehow and a lot of applications cannot connect anymore to mysql (don’t ask me why, I just want my doc back to return to my real work).

I’m not posting here to get help to fix my problem but I was wondering if Yunohost should stop the upgrade process at the first app which failed so it would not upgrade the ones that are still working.

2 Likes

So I end up debugging this situation, the problems where:

  • synapse required for fail2ban to parse some log file but the log file didn’t existed
  • shaarli log file were a … directory :expressionless: details are here

So both those problems were preventing fail2ban to reload which breaked all php apps upgrades.

Nevertheless, the discussion here is not really about this specific situation but more about: how could we make our apps upgrade more robust? Here 2 other apps broke the upgrade of several other apps :confused:

The most obvious improvement would be already to stop upgrading apps if one app upgrade failed I guess?

I know a lot of work is already been made by backuping most apps before upgrading and restoring on failure. I know there is also this huge discussion about totally changing the upgrade mechanism by moving to a closer one of fedora with only a limited stick number of operations allowed but it’s like a titan work here :sweat_smile:

2 Likes

Ouch, sorry to hear about the troubles. It won’t help you much now but just to share my process for upgrading: I typically run a full backup of the system first. Then, I fire up a new Hetzner Cloud €3 VPS and restore the system there. Then I run the upgrade on this “expendable” VPS and see what happens. If there are bugs, I come and create issues / threads on the forum. See YunoHost • index for more on the steps.

The most obvious improvement would be already to stop upgrading apps if one app upgrade failed I guess?

Yes, that sounds good.

Hm yes

Also that reminds me a lot about situation where stuff would break the PHP-FPM daemon and stuff happening after would miserably crash … Nowadays that’s kind of mitigated with a check that important services like nginx and php are running before running app scripts, but that’s still not the case for fail2ban which happens to be the case here …

Tricky thing is that we don’t have an easy way to test that an app interfaces with fail2ban since they probably don’t list it in the “services” thing in the manifest.json. We could, however, grep the scripts for anything related to fail2ban and in that case require fail2ban to be up and running …

Funny thing is that here it’s actually php-fpm upgrade that needed fail2ban to be up and running so that wouldn’t even help ^^’

That would be a good way to avoid breaking (too much) stuff.
Then we could upgrade the apps without the broken one(s), at least.

(and I guess it’s the easiest way to do it right now, before coming up with a better solution ?)

@FurryJulie btw if in the future you need help wtih Wallabag or Shaarli, feel free to ping me :slight_smile:
(I just landed a fix for Shaarli, not sure if it can help you in your case)

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.