J’ai rapidement essayé de faire l’upgrade depuis la 18.0.2 mais ça a cassé fail2ban et l’installation a échouée.
Du coup Nextcoud a été désinstallé … j’ai essayé de restaurer depuis l’archive de pré-upgrade mais sans succès
Je te fais suivre le log de la restauration en DM.
Edit 1 :
Autres info :
Impossible de redémarrer fail2ban donc restauration et réinstallation impossible
Rien dans /var/log/nextcloud : vide
Edit 2 :
Alors, après un
yunohost tools regen-conf fail2ban --force
service fail2ban reload
service fail2ban restart
j’ai pu faire redémarrer fail2ban.
Du coup, j’ai pu réinstaller Nextcloud mais contrairement aux fichiers qui sont toujours là, les applications tierces à Nextcloud ne sont plus là et leurs données avec : Contacts, Agenda, SMS, etc.
Je vais maintenant tenter une restauration depuis la pré-upgrade pour voir si tout revient bien.
Peut-être un indice qui a mis le bazar avec fail2ban : j’ai un port exotique dans la configuration, un mailto avec un sender différents, des bantime et find time différents et des options d’actions différentes de la configuration par défaut.
J’ai d’ailleurs été obligé de regénérer le configuration par défaut de fail2ban pour pouvoir arriver à le redémarrer puis restaurer.
Ensuite, j’ai pu reconfigurer fail2ban avec mes valeurs et le redémarrer.
/var/www/nextcloud# sudo -u www-data php occ maintenance:mode --off
This version of Nextcloud requires at least PHP 7.2<br/>You are currently running 7.0.33-26+0~20200320.33+debian9~1.gbp746b8e. Please update your PHP version.
Ici c’est souvent pour quand ça marche pas mais quand ça marche il faut le dire aussi. le passage de Nextcloud 15 a 18 s’est fait pour moi sans douleur et sans aucun problèmes.
Merci donc à l’équipe qui a packagé l’app !
Maj qui s’est passé niquel pour moi aussi (15.x (15.14 je crois, enfin la dernière version) vers 18.2) sur un RPI 3B+ avec Yuno 3.7.x (dernière version aussi)
J’ai du la faire 2 fois tout de même, la première il ne s’est rien passé (j’ai eu une coupure internet de mon client ssh) après avoir attendu une journée et ne s’étant rien passé j’ai fais de nouvelles maj de yuno (sur php) qui n’étaient pas dispos avant (je sais pas si c’est un hasard ou pas). Puis j’ai relancé la maj de nextcloud, tout s’est passé niquel.
Elle a duré environ 45 mins je crois. J’ai ensuite constaté que le serveur faisait bcp de taches en arrière plan (grand charge système). J’ai donc attendu que ça se calme (1 ou 2h) puis j’ai redémarré mon serveur.
Et donc tout c’est passé niquel, je n’ai pas constaté de perte de données pour l’instant.
Il m’a juste fallu mettre à jours les appli calendrier et contact puis à les activer.
Voilà pour les prochains,
Merci à toute la team dev et packaging de Nextcloud Yuno pour leurs formidable travail !
Merci à toute la team de Yuno Core pour ce superbe boulot aussi !
Last week I upgraded fine to v18 (no maintenance mode issue btw) on ynh 3.7 (upgraded now to 3.7.1.1). However, now I’m facing a ~20 second delay when sending an initial request to Nextcloud. I’m on a Pi 3 B+, which isn’t the fastest of course, but the initial response was always <500ms. Consecutive page loads are fine though. It’s just really annoying when you open keepass2android, it just takes too long to get a password now
Any idea if something changed with the amount of workers, or if this is a php7.3 related issue? Other apps (like Rainloop) load instantly…
I’m trying to make an update of nextcloud form 15.x to 18.0.3 and i have a suggestion is to download first all sources before update… just because at now the script is downloading nextcloud sources at 25kb/s and it’s not my connection because youtube works properly and when i test with wget sources it’s very slow.
From Nextcloud 15 to 18 we indeed change the number of workers. It was initially set to 10 maximum.
Now, well, it’s a little bit more complicated…
If I’m not mistaking, a Pi 3 B+ is a 4 cores with 1Gb ram.
So, the maximum of workers is set according to this formula:
total_ram / 2 / footprint, and can’t exceed 4 times the number of core.
You have 1Gb of ram, Nextcloud is considering having a footprint of 50Mo. So you should have 1000 / 2 / 50 = 10 workers max.
With a processor with 4 cores, your limit is 16 workers maximum. You’re not above the limit.
So, you should have still the same number of workers, 10.
And, I just had a look to other specifications about how to deal with the workers, for your configuration, it will be approximately the same, even slightly more reactive.
So… I guess nextcloud is less reactive in this last version…
To be sure, you can have a look to your fpm config for nextcloud /etc/php/7.3/fpm/pool.d/nextcloud.conf
You should have (according to my counts)
I see 4 running (max_spare I guess), when I start a fresh connection one of them goes nuts (100% cpu), other three are at 0%. No extra children spawn during this. No disk I/O, memory at 400MB, swap at 5MB.
Browsing folders is within 100ms, cpu never reaches more than 30%, but other children appear more active in sharing the load. Doing a (ctrl-)F5 is done in 5 seconds (considered normal) and done with extra children.
Meanwhile I’m trying to figure out what might have changed in Nextcloud, but because of the jump of several major releases (15->18) it’s hard to track. I disabled the “Add notes links and comments”-“feature”, as others complained about performance, but that didn’t help.
I’m contemplating doing another Nextcloud installation on my domain to see if it is really my specific Nextcloud instance or a more general issue. Just not sure if they would bite each other?
And really, thanks for this and all the great things you’re doing for Yunohost! I was looking forward to these updates so I can properly add users now with the new permissions system.
I’m running some tests on my side too, on my VM with a single core and 1G ram, I have 4 max_children and 1 min_spare_servers and start_servers.
So, before using nextcloud, I had only one child running.
Same if I let nextcloud unused for some time, I return to min_spare_servers.
With only 1 child, my nextcloud needs a lot of time to start, and the only child is stressed at 100% CPU.
Reusing it immediately after goes smoothly (3 children running).
I modified my fpm config with 2 min_spare_servers, it was much better.
So I think the problem is, for example for you that only 1 min_spare_servers is not enough for such a heavy app.
By the way, on the same VM, I confirm that a light app, with no child when idle, start without problem.
So, we need some adjustments on min_spare_servers for heavy apps.
I’ll work on it this evening or tomorrow and I’ll try to add this to the next release 3.8
Let me play around with my settings more. I see 4 children running and doing nothing and still on first connection one of them goes 100% for >20 secs while the other children are doing nothing. I don’t think increasing min_spare_servers does much then.
Update: nope, 5 servers now and no improvement… Your change may help with other workloads though/in general.
Is the multi instance now fully working on one single domain?
You increased your min_spare_servers to 4, and still only one goes to 100% !? That’s a strange behavior !
When I raise my min_spare_servers the load was shared between them.
I’m gonna retry that
Huh, is it related or a completely different question ?
Browsing and page refresh load is spread around the servers. Fresh connections only one server is used (and pulled to 100% and the rest remains 0%). Just opening an incognito window and logging into Yunohost is fast, then clicking Nextcloud and it will do the 100% on one server thing.
It is related in the sense that I want to do a fresh install of Nextcloud next to my running one to see if it shows the same behavior. TBH, I really hope it is behaving the same because I am not looking forward to migrate my data again…
For the first start, I had the 2 start_servers, the first got 70% cpu before the second get 40% and share the load, soon after I got 4 alive.
I’m waiting for the children to go down…
Lost my patience and put start_servers to 1, the children didn’t want to die ! Bad children…
With only 1 child, the proc went to 106% before anything else spawn.
Now I move to
pm = dynamic
pm.max_children = 9
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 6
Hmm, indeed, a child got 106% for 1s before the 3 others came to share the load.
And a second time after a restart of php-fpm, the first one got 40% then share with the others.
Looks like it’s more a question of how fast the processor behave regarding the load of php-fpm. I turn my VM to 4 cores for the test.
I’m talking about the spawn of children only, not the time the page needs to load.
But I’m about to try the difference right now about the time needed to load the first time.
