Matériel: Brique Internet avec VPN
Version de YunoHost: 3.8.4
J’ai accès à mon serveur : En SSH
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Bonjour
J’ai essayé 2 fois de faire la MAJ Roundcube et 2 fois, ça été un échec…
Le log est ici et je ne comprends pas trop ce qui fait planter la MAJ…
J’ai regardé sur le forum, mais je n’ai rien trouvé qui correspondait à cela.
Merci de votre aide 
Mouarf ben comme d’autres gens, le process se fait tué, ce qui semble indiquer un manque de mémoire ram … (J’ai du mal à comprendre pourquoi ce genre de soucis semble survenir depuis quelques mois)
Si ca n’arrivait pas avant alors que les gens faisaient la même chose, et si le code des apps n’a pas littéralement explosé en terme de consommation lors de la compilation, c’est sûrement dû à la gestion de la ram au niveau kernel quoi n’est peut-être pas libérée comme il le faudrait.
Je vois bien ça avec mes autres serveurs Linux, c’est différence entre kernel et la façon dont ils gèrent la RAM et la swap, y a eu des gros changements durant la dernière année écoulée. Mais ce n’est qu’une hypothèse.
Merci pour vos réponses
Donc si je comprends bien, il n’y a pas vraiment de solution à part changer de matériel ?
@Brice si si y a des solutions.
Combien d’applications tu as d’installées ?
Il faudrait verifier combien de mémoire au cours du processus tu as de consommé. On Peut tuer quelques instances, et on peut augmenter la swap aussi
J’ai 4 applications : Nextcloud, Wifi Hotspot, VPN Client et Roundcube.
Aux niveaux ressources, voici ce que donne yunohost diagnosis get systemresources
id: systemresources
items:
0:
data:
available: 647 MiB
available_percent: 64
total: 1002 MiB
meta:
test: ram
status: SUCCESS
summary: diagnosis_ram_ok
1:
data:
recommended: 512 MiB
total: 0.0 B
details: diagnosis_swap_tip
meta:
test: swap
status: INFO
summary: diagnosis_swap_none
2:
data:
device: /dev/mmcblk0p1
free: 5.4 GiB
free_percent: 40
total: 14 GiB
meta:
mountpoint: /
test: diskusage
status: SUCCESS
summary: diagnosis_diskusage_ok
timestamp: 1594574160```(C’est potentiellement plus pratique de faire un yunohost diagnosis show systemresources --human-readable)
Mais à part ça ce qu’on voit c’est qu’il reste 600Mo de RAM dispo ce qui est tout a fait raisonnable pour installer/upgrader une app à priori…
Ah ok merci, en effet, c’est un peu plus agréable à lire !
Du coup, par rapport à ce que me conseillais @boistordu, comment dois-je procéder pour tuer provisoirement quelques instances ?
Potentiellement tu peux lister les process les plus gourmands en mémoire et on peut voir à partir de là, mais en vrai c’est juste pas normal de pas pouvoir installer roundcube avec 600Mo de RAM libre … :
ps aux --sort %mem | tail -n 10
Ça dépend ce que l’installation de roundcube demande comme process. Si y a une compilation ou un npm…
De plus il semblerait que les derniers firmwares font en sorte d’essayer de garder 200 ou 100M dans la ram en cache avec 0 en free mais donc de ne pas utiliser tout pour l’installation
J’ai 4 applications : Nextcloud, Wifi Hotspot, VPN Client et Roundcube.
@Brice ah oui ça fait vraiment rien pratiquement.
Bon la seule appli que tu peux « descendre » c’est nextcloud. Pour ça en général je le fais en faisant un systemctl stop php-fpm il me semble. Je me connecte donc en ssh en root sur l’appareil.
Il est important aussi de ne pas faire ta mise à jour ou ton installation via l’interface web. J’ai pu remarquer que ça consommait beaucoup de ressources en plus ce qui fait bien souvent planter mes installations.
Donc tu dois utiliser les commandes comme yunohost app upgrade roundcube etc
Tu devrais rajouter le paramètre —debug Pour bien faire comme ça tu verras à quel moment ça bug et si c’est répétitif.
L’étape d’après c’est d’augmenter la partition swap ou plus exactement d’en ajouter une et/ou un fichier swap.
Désolé pour le délai de réponse (des soucis avec mon FAI…)
Voici ce que donne ps aux --sort %mem | tail -n 10 :
_rspamd 1925 0.0 2.9 93132 30068 ? S juil.25 1:08 rspamd: controller process (localhost:11334)
_rspamd 906 0.0 2.9 88028 30400 ? Ss juil.25 0:04 rspamd: main process
root 704 0.0 3.0 259628 31324 ? Ss juil.25 0:11 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
root 2772 0.0 3.3 188252 34348 ? Ss juil.25 0:11 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
_rspamd 1926 0.0 3.3 92736 34604 ? SL juil.25 0:38 rspamd: normal process (localhost:11333)
nextclo+ 28013 1.0 4.8 269468 49612 ? S 15:12 1:20 php-fpm: pool nextcloud
nextclo+ 29547 1.3 4.8 269480 49776 ? S 16:42 0:30 php-fpm: pool nextcloud
nextclo+ 28016 1.0 4.8 269548 49984 ? S 15:12 1:20 php-fpm: pool nextcloud
nextclo+ 27084 1.0 4.8 269644 50040 ? S 14:11 1:58 php-fpm: pool nextcloud
mysql 868 0.5 8.7 584748 89628 ? Ssl juil.25 9:41 /usr/sbin/mysqld
Mais j’avoue que j’ai du mal à l’interpréter. Je crois voir que c’est Nextcloud qui prend le plus de RAM (ce qui me parait normal).
Merci de tes explications
systemctl stop php-fpm me renvoie :
Failed to stop php-fpm.service: Unit php-fpm.service not loaded.
Pour les mises à jour, j’avais remarqué que l’interface WEB posaient en effet certains problèmes. Depuis déjà plusieurs mois, j’ai donc désactivé l’interface WEB admin et je fait tout en SSH.
Je vais esayer la MAJ avec -debug.
Pour le swap, je vais essayer d’en ajouter. Par contre, d’après ce que j’ai vu ici, c’est mieux de créer le fichier SWAP sur une clé et pas sur la SD. Si j’ai bien compris ce qui est noté sur ce même post, je peux suivre cette page pour créer le SWAP ? (à voir comment je me débrouille sachant que l’anglais n’est pas fort…)
Et t es sûr que nextcloud est lancé ?
Si tu as un disque dur par exemple pour le fichier swap qui est branché, c’est encore mieux
Fais uniquement le swap file pour le moment. Pas les autres types de swap
J ai compris notre erreur. C est pas php-fpm mais il php version fpm
Quand tu es à stop php, fais deux fois tab tu verras y en a un ou plusieurs avec des numéros. Tu les stoppes tous
Ok pour le SWAP.
Je te confirme que Nextcloud est bien lancé (j’ai bien accès à l’interface en ligne via le sso) et quand je lance un diagnostic sur le serveur, je n’ai aucun problème signalé.
J’ai donc essayé avec systemctl stop il php version fpm, mais cela me donne le même type de message :
Failed to stop il.service: Unit il.service not loaded.
Failed to stop php.service: Unit php.service not loaded.
Failed to stop version.service: Unit version.service not loaded.
Failed to stop fpm.service: Unit fpm.service not loaded.
Ça m apprendra à faire des messages dans les transports en communs. J’ ai pas vérifié ce que je t écrivais.
Donc je disais il y a plusieurs versions de php-fpm donc tu dois désactiver la Bonne version. Essaie de la trouver avec tab
Merci de ta réponse.
Au final, avant de chercher à désactiver la bonne version de php-fpm, j’ai tenté la migration vers Yunohost 4 / Debian Buster. Migration qui s’est bien passé.
J’ai retenté ensuite la MAJ de Rouncube et ça a fonctionné !
Donc problème résolu 
Je précise qu’après la migration, j’ai refait un diagnostic des ressources et j’ai constaté que la RAM avait 715Mo de dispo (soit 115Mo en plus que lors de mon test le 13 juillet)