API yunohost ne répond pas systématiquement après màj de yunohost

[tomdereub]

Mon serveur YunoHost

Matériel: Ordi portable 64 bits
Version de YunoHost: 3.8.4.7
J’ai accès à mon serveur : En SSH et Par la webadmin et En direct avec un clavier/écran…
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui, instance qui a au moins 4 ans, qui a migré à chaque fois.

Description du problème

J’ai l’impression qu’à chaque mise à jour de yunohost (juste yunohost, pas les autres mises à jours de paquets debian ou autres), l’api ne redémarre pas toute seule. Pas vraiment un problème pour moi, j’ai juste à la relancer en ligne de commande, mais ça peut être gênant pour quelqu’un qui n’est pas à l’aise avec, donc je mets les infos ici :

sudo systemctl status yunohost-api
● yunohost-api.service - YunoHost API Server
   Loaded: loaded (/lib/systemd/system/yunohost-api.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2020-06-11 10:08:56 CEST; 42min ago
 Main PID: 15601 (code=exited, status=1/FAILURE)

juin 11 10:08:56 lamo systemd[1]: yunohost-api.service: Start request repeated too quickly.
juin 11 10:08:56 lamo systemd[1]: Failed to start YunoHost API Server.
juin 11 10:08:56 lamo systemd[1]: yunohost-api.service: Unit entered failed state.
juin 11 10:08:56 lamo systemd[1]: yunohost-api.service: Failed with result 'exit-code'.
juin 11 10:09:02 lamo yunohost-api[7984]: Traitement des actions différées (« triggers ») pour systemd (232-25+deb9u1
juin 11 10:09:03 lamo yunohost-api[7984]: Paramétrage de yunohost-admin (3.8.3.4) ...
juin 11 10:09:04 lamo yunohost-api[7984]: Traitement des actions différées (« triggers ») pour man-db (2.7.6.1-2) ...
juin 11 10:09:10 lamo yunohost-api[7984]: Done!
juin 11 10:09:10 lamo yunohost-api[7984]: La mise à jour des paquets de YunoHost est finie !
juin 11 10:09:10 lamo yunohost-api[7984]: Pressez [Entrée] pour revenir à la ligne de commande

Si besoins de plus de logs je peux en fournir, mais je n’ai pas trouvé de mention de yunohost-api dans les logs de la mise à jour.

[Aleks]

Tu peux faire un

journalctl -u yunohost-api -u 1000 --no-pager --no-hostname

[tomdereub]

admin@lamo:~$ sudo journalctl -u yunohost-api -u 1000 --no-pager --no-hostname
-- No entries --

[Aleks]

Ou bien ptete

tail -n 100 /var/log/yunohost/yunohost-api.log

[tomdereub]

Voici : https://paste.yunohost.org/icogapiquz

[Aleks]

Arf ben du coup désolé le log remonte pas assez loin alors essayons plutôt avec -n 300

[tomdereub]

Ok, je t’ai mis tous les logs du 11/06, il y a un peu plus de 300 lignes…
Edit : avec le lien c’est mieux : https://paste.yunohost.org/uyagipunob.bash

[Aleks]

Beh du coup le soucis semble venir de :

error: [Errno 98] Address already in use: ('localhost', 6787)

Mais j’ai du mal à piger pourquoi un process serait déjà en train d’utiliser ce port à part si tu as lancé un truc manuellement sur ce port là…

[ljf]

Tu utilises quoi comme apps ?

[tomdereub]

Le coup de devoir relancer la yunohost-api après une mise à jour, ça me le fait systématiquement (et jamais à d’autres moments), donc instinctivement je dirais que c’est lié au processus de mise à jour et pas à une app.
Mais voici ma liste d’apps :

• Etherpad
• I hate money
• Lufi
• Mailman
• Mattermost
• Nextcloud
• OnlyOffice
• Opensondage
• Peertube
• Rainloop
• restic
• ssh chroot directory
• transmission
• wordpress (2 instances)
• zerobin

[ljf]

Ce qui me faisait penser ça,c’est que ça pourrait être un soucis avec une app qui a réservé le port de yunohost-api… Ou l’app monit https://github.com/YunoHost-Apps/monit_ynh/issues/4
Mais du coup il faudrait faire une petite enquête au prochain upgrade pour déterminer quel est le programme qui écoute sur ce port…

[tomdereub]

Je viens de faire la mise à jour vers ynh 3.8.9.4, et pas eu de souci cette fois-ci… Il suffisait de le dire !