Ici il y a tout de même un regen-conf à appliquer
et ici aussi
Tu devrais déjà exécuter cela
yunohost tools regen-conf --force
Je regarde les applications installées.
- Dokuwiki
- Borgserver / Borg Backup
- Element
- FreshRSS
- Nextcloud
- Synapse
- Vaultwarden
J’essaye de chercher dans les dépôts github des app pour voir si je trouve quelque chose qui indique que nchan est une dépendance de l’un ou l’autre mais je ne trouve pas.
Où est-ce que je peux voir les dépendances installée avec une application ?
Oui, j’ai bien ce paquet d’ailleurs… et j’ai bien aussi le paquet libnginx-mod-nchan installé, il doit aussi être là d’origine… Désolé pour la confusion
Pas de problème, merci pour le temps passé à essayer de m’aider. 
J’ai pu restaurer nextcloud mais j’arrive sur :
Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.
C’est pas encore terminé…
J’ai régénéré la configuration comme tu l’as proposé :
# yunohost tools regen-conf --force
Success! Configuration updated for 'yunohost'
Success! Configuration updated for 'apt'
Success! Configuration updated for 'dnsmasq'
apt:
applied:
/etc/apt/sources.list.d/extra_php_version.list:
status: force-updated
pending:
dnsmasq:
applied:
/etc/resolv.dnsmasq.conf:
status: updated
pending:
yunohost:
applied:
/etc/systemd/system/ntp.service.d/ynh-override.conf:
status: force-removed
pending:
Je viens de me rendre compte que Gitea était également désinstallé.
# yunohost backup restore gitea-pre-upgrade1
(...)
Success! Restoration completed
Je confirme que j’ai à nouveau accès à Gitea.
Et actuellement, Nextcloud est toujours planté (internal server error).
Un sudo htop ou sudo btop pourrait éclairer un peu. Peut être un reboot
J’ai fait un reboot, ça n’a rien changé pour nextcloud.
$ sudo htop
sudo btop
Je ne vois rien d’anormal jusqu’ici. Le serveur est à la cool, pas trop de mémoire utilisée, pas trop de trafic réseau, …
Pour mettre le serveur complètement à jour, je dois appliquer une mise à jour pour Element, pour Synapse et pour Nextcloud.
La dernière fois je l’avais fait via la webadmin mais peut-être que c’est ça qui a causé le problème ? Ici j’ai décidé de le faire en ligne de commande, dans tmux pour être sûr.
# yunohost app upgrade element
Info: Now upgrading element…
(...)
Success! Upgrade complete
Element fonctionne. On passe à la suite.
# yunohost app upgrade synapse
Info: Now upgrading synapse…
(...)
Success! synapse upgraded
Ça semble OK pour Synapse également.
Je lance l’upgrade pour nextcloud.
# yunohost app upgrade nextcloud
(...)
Success! nextcloud upgraded
Yes, Nextcloud fonctionne à nouveau ! 
Résumons…
Nginx a commencé à mettre plus de temps à démarrer (pourquoi? C’est encore un mystère…). À cause de ça, plusieurs mises à jours d’application se sont mal passés (Gitea sans que je m’en rende compte, Element et puis Nextcloud).
La solution a été d’augmenter le temps avant un timeout.
[Service]
Type=forking
PIDFile=/run/nginx.pid
(...)
TimeoutStartSec=300
Grâce à ça, j’ai pu restaurer Gitea et ensuite mettre à jour Element, Synapse et puis Nextcloud (qui était planté..). J’ai à nouveau un serveur fonctionnel.
Cependant je n’ai toujours pas compris ce qui rend le démarrage de Nginx si lent. Ça me semble anormal de devoir mettre un délais avant timeout de 5 minutes.
J’ai donc du mal à considérer le problème comme résolu.
Je vois deux pistes :
- Le serveur est surchargé (semble peu probable.. Là il tourne avec un load average de ~0,20 par exemple.. Il est pas chargé au niveau réseau ni disque dur, ni RAM…)
- Un problème à cause du module nginx nchan ?
Voyez-vous une autre possibilité ?
En fait, je pensais ouvrir trois ou quatre terminaux. Un avec sudo btop, un autre avec sudo journalctl -f, un autre avec sudo iotop et un dernier pour lancer sudo systemctl restart nginx .
Y’aura bien un qui va dire ce qui se passe
Bonsoir,
Si ce n’est déjà fait, peut-être peux-tu mettre temporairement* error_log /var/log/nginx/error.log debug ; pour des logs un peu plus verbeux et recréer la condition du plantage en ramenant le timeout à 90 ?
(*c’est effroyablement verbeux)
Je n’ai plus eu le temps hier et la semaine a recommencé… J’essaye de tester vos propositions au plus vite.