Bouton login de la webadmin suite à màj

Mon serveur YunoHost

Matériel: Serveur loué chez OVH
Version de YunoHost: 11.1.9
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

Description du problème

Bonjour,
suite à une mise à jour de mon serveur via la webadmin, je n’ai plus d’accès via la webadmin (le bouton login est désactivé) et maintenant nextcloud est inaccessible (erreur http 500), mais ce n’est peut-être pas lié.
Si quelqu’un pouvait m’aider dans mes recherches, je ne sais pas bien où regarder. Merci d’avance.

Voici ce que j’ai fait, via la ligne de commande :

  • recherche de log avec yunohost log list, pas trouvé d’erreur
  • yunohost tools migrations list me dit que toutes les migrations sont faites (done)
  • yunohost service status me dit que mysql est enabled mais DEAD
  • sudo ps -ef | grep mysql ne retourne rien
  • si je tente yunohost tools migrations state j’ai un message d’erreur qui me dit “Another YunoHost command is running…”
  • idem si je tente yunohost diagnosis run
  • en faisant cat /var/run/moulinette_yunohost.lock je vois que le process 5528 est en cours d’execution, il s’agit de /usr/bin/yunohost-api

… donc je me dis que lors de la migration mysql s’est planté, que yunohost-api attend quelque chose de mysql, et ne termine pas la migration, d’où l’impossibilité de se connecter. Nextcloud a fonctionné après cet incident, jusqu’à ce qu’il ait besoin de mysql.

Que j’ai raison ou non, que devrais-je faire maintenant ? j’ai un peu peur de faire des bêtises, plus de mal que de bien…
Merci de vos conseils.

suite de mes investigations :
je viens de trouver les logs mysql :

  - Feb 21 18:13:32 mariadbd[22135]: 2023-02-21 18:13:32 938 [Warning] Aborted connection 938 to db: 'nextcloud__2' user: 'nextcloud__2' host: 'localhost' (Got an error reading communication packets)
  - Feb 21 18:20:43 mariadbd[22135]: 2023-02-21 18:20:43 1332 [Warning] Aborted connection 1332 to db: 'nextcloud__2' user: 'nextcloud__2' host: 'localhost' (Got an error reading communication packets)
  - May 01 06:55:01 systemd[1]: Stopping MariaDB 10.5.18 database server...
  - May 01 06:55:01 mariadbd[22135]: 2023-05-01  6:55:01 0 [Note] /usr/sbin/mariadbd (initiated by: unknown): Normal shutdown
  - May 01 06:55:01 mariadbd[22135]: 2023-05-01  6:55:01 0 [Note] Event Scheduler: Purging the queue. 0 events
  - May 01 06:55:01 mariadbd[22135]: 2023-05-01  6:55:01 0 [Note] InnoDB: FTS optimize thread exiting.
  - May 01 06:55:02 mariadbd[22135]: 2023-05-01  6:55:02 0 [Note] InnoDB: Starting shutdown...
  - May 01 06:55:02 mariadbd[22135]: 2023-05-01  6:55:02 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool
  - May 01 06:55:02 mariadbd[22135]: 2023-05-01  6:55:02 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
  - May 01 06:55:02 mariadbd[22135]: 2023-05-01  6:55:02 0 [Note] InnoDB: Buffer pool(s) dump completed at 230501  6:55:02
  - May 01 06:55:02 mariadbd[22135]: 2023-05-01  6:55:02 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
  - May 01 06:55:02 mariadbd[22135]: 2023-05-01  6:55:02 0 [Note] InnoDB: Shutdown completed; log sequence number 341489994657; transaction id 337206587
  - May 01 06:55:03 mariadbd[22135]: 2023-05-01  6:55:03 0 [Note] /usr/sbin/mariadbd: Shutdown complete
  - May 01 06:55:03 systemd[1]: mariadb.service: Succeeded.
  - May 01 06:55:03 systemd[1]: Stopped MariaDB 10.5.18 database server.

``
`

Hmokay dans ce cas essayons de voir ce qu’est en train de faire yunohost-api :

ps -ef --forest | grep -A10 yunohost-api

Bonjour,
merci de consacrer du temps à mon problème.

l’option --forest ne retourne rien (ou alors c’est très long…)
donc voici sans

sudo ps -ef  | grep -A10 yunohost-api
root      5528     1  0 Feb21 ?        00:01:14 /usr/bin/python3 /usr/bin/yunohost-api
root      6284     1  0 Feb21 ?        00:18:28 /usr/sbin/irqbalance --foreground
root      6392 22867  0 Apr22 ?        00:00:00 /usr/sbin/CRON -f
root      6394  6392  0 Apr22 ?        00:00:00 /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
root      6396  6394  0 Apr22 ?        00:00:00 /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
root      6398  6396  0 Apr22 ?        00:00:00 run-parts --report /etc/cron.daily
root      6415  6398  0 Apr22 ?        00:00:00 /bin/bash /etc/cron.daily/yunohost-certificate-renew
root      6416  6415  1 Apr22 ?        04:10:22 /usr/bin/python3 /usr/bin/yunohost domain cert renew --email
root      6681 22867  0 Apr28 ?        00:00:00 /usr/sbin/CRON -f
root      6686  6681  0 Apr28 ?        00:00:00 /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
root      6687  6686  0 Apr28 ?        00:00:00 /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
--
admin    17215  9832  0 16:22 pts/1    00:00:00 grep -A10 yunohost-api
root     17217 17214  0 16:22 pts/1    00:00:00 ps -ef
root     17313 22867  0 Apr29 ?        00:00:00 /usr/sbin/CRON -f
root     17317 17313  0 Apr29 ?        00:00:00 /bin/bash -c : YunoHost Automatic Diagnosis; sleep $((RANDOM%1200)); yunohost diagnosis run --email > /dev/null 2>/dev/null || echo "Running the automatic diagnosis failed miserably"
root     17424 16928  0 May03 ?        00:30:06 /usr/bin/python3 /usr/bin/yunohost diagnosis run --email
root     17838 17317  0 Apr29 ?        01:15:02 /usr/bin/python3 /usr/bin/yunohost diagnosis run --email
root     18545     1  0 Feb21 ?        00:08:09 php-fpm: master process (/etc/php/8.1/fpm/php-fpm.conf)
root     18570 22867  0 Apr22 ?        00:00:00 /usr/sbin/CRON -f
root     18573 18570  0 Apr22 ?        00:00:00 /bin/bash -c : YunoHost Automatic Diagnosis; sleep $((RANDOM%1200)); yunohost diagnosis run --email > /dev/null 2>/dev/null || echo "Running the automatic diagnosis failed miserably"
root     18975 18573  0 Apr22 ?        02:47:34 /usr/bin/python3 /usr/bin/yunohost diagnosis run --email
root     19070     1  0 May01 ?        00:00:00 /bin/sh /usr/lib/apt/apt.systemd.daily install

voici aussi un résultat qui avait été demandé dans une autre file de discussion

sudo ps -ef  | grep -C3 $(cat /var/run/moulinette_yunohost.lock)
root      4923  4922  0 May03 ?        00:00:00 run-parts --report /etc/cron.daily
root      4941  4923  0 May03 ?        00:00:00 /bin/bash /etc/cron.daily/yunohost-certificate-renew
root      4942  4941  1 May03 ?        00:32:19 /usr/bin/python3 /usr/bin/yunohost domain cert renew --email
root      5528     1  0 Feb21 ?        00:01:14 /usr/bin/python3 /usr/bin/yunohost-api
root      6284     1  0 Feb21 ?        00:18:15 /usr/sbin/irqbalance --foreground
root      6392 22867  0 Apr22 ?        00:00:00 /usr/sbin/CRON -f
root      6394  6392  0 Apr22 ?        00:00:00 /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
--
root      6688  6687  0 Apr28 ?        00:00:00 run-parts --report /etc/cron.daily
root      6705  6688  0 Apr28 ?        00:00:00 /bin/bash /etc/cron.daily/yunohost-certificate-renew
root      6706  6705  1 Apr28 ?        02:08:15 /usr/bin/python3 /usr/bin/yunohost domain cert renew --email
root      7205  5528  0 Apr21 ?        00:00:00 sh -c lsof /var/lib/dpkg/lock >/dev/null
root      7208  7205  0 Apr21 ?        00:00:00 lsof /var/lib/dpkg/lock
root      7209  7208  0 Apr21 ?        00:00:00 lsof /var/lib/dpkg/lock
root      7640 22867  0 May02 ?        00:00:00 /usr/sbin/CRON -f
--
root     11422  9951  0 Apr27 ?        01:34:31 /usr/bin/python3 /usr/bin/yunohost diagnosis run --email
root     11658     2  0 18:35 ?        00:00:00 [kworker/u8:0-events_unbound]
root     11757 11065  0 18:38 pts/1    00:00:00 sudo ps -ef
admin    11758 11065  0 18:38 pts/1    00:00:00 grep -C3 5528
root     11761 11757  0 18:38 pts/1    00:00:00 ps -ef
root     12115 22867  0 00:36 ?        00:00:00 /usr/sbin/CRON -f
root     12117 12115  0 00:36 ?        00:00:00 /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Uuuh ok mais la construction de la commande est faite pour voir quelles sont les sous-commandes lancées par yunohost-api, et est censée renvoyer exactement 10 lignes … Sans l’option --forest le retour de la commande n’est pas vraiment intéressant x_x

bonjour,
l’option --forest marche bien sur mon PC Ubuntu, mais pas sur le serveur.
Je fais une autre tentative

root@laborderie:/home/admin# ps -ejH  | grep -A10 yunohost-api
 5528  5528  5528 ?        00:01:14   yunohost-api
 7205  5528  5528 ?        00:00:00     sh
 7208  5528  5528 ?        00:00:00       lsof
 7209  5528  5528 ?        00:00:00         lsof
18545 18545 18545 ?        00:08:13   php-fpm8.1
28271 18545 18545 ?        00:00:00     php-fpm8.1
28272 18545 18545 ?        00:00:00     php-fpm8.1
27594 18545 18545 ?        00:00:05     php-fpm8.1
27617 18545 18545 ?        00:00:05     php-fpm8.1
27635 18545 18545 ?        00:00:05     php-fpm8.1
27680 18545 18545 ?        00:00:05     php-fpm8.1

et aussi je remarqué que j’ai 15 fois cron qui lance run-parts->yunohost-certif->yunohost. C’est normal ?

et aussi, si mariaDB ne fonctionne pas, c’est probablement parce que la migration ne s’est pas faite correctement

sudo dpkg --audit
Another process has locked the database for writing, and might currently be
modifying it, some of the following problems might just be due to that.

The following packages are in a mess due to serious problems during
installation.  They must be reinstalled for them (and any packages
that depend on them) to function properly:
 mariadb-server-10.5  MariaDB database server binaries

The following packages have been unpacked but not yet configured.
They must be configured using dpkg --configure or the configure
menu option in dselect for them to work:
 mariadb-client-10.5  MariaDB database client binaries
 mariadb-client-core-10.5 MariaDB database core client binaries
 mariadb-server-core-10.5 MariaDB database core server files

The following packages have been triggered, but the trigger processing
has not yet been done.  Trigger processing can be requested using
dselect or dpkg --configure --pending (or dpkg --triggers-only):
 man-db               tools for reading manual pages

Voici un résumé des opérations faites pour résoudre le problème. Pour servir de trace, et d’inspiration à celui/celle qui aura un problème similaire.

Je ne peux exécuter le diagnostic et autres opérations car il y a un processus qui bloque le lancement d’autres opérations.
admin@laborderie:~$ sudo yunohost diagnosis run
Warning: Another YunoHost command is running right now, we are waiting for it to finish before running this one
Warning: Still waiting…
Warning: Still waiting…

admin@laborderie:~$ cat /var/run/moulinette_yunohost.lock
5528

c’est le processus 5528 qui bloque.
5528 = yunohost-api

je le tue.
kill 5528

sudo yunohost service status
indique yunohost-api working, probablement que la commande ne retourne pas une information à jour.

sudo yunohost service stop yunohost-api
sudo yunohost service start yunohost-api
maintenant je peux me logger à l’interface web
et maintenant j’ai plein d’infos en allant dans la section Diagnosis

Je suis les instructions et redémarre mysql avec sudo yunohost service start mysql comme suggéré
et je n’ai plus d’erreur dans le diagnostic !

Tentative de faire un upgrade système
mais échec car il y a déja une migration en cours. Le message suggestion de faire
sudo dpkg --audit
sudo apt install --fix-broken
sudo dpkg --configure -a
mais il y a de nouveau un problème de fichier vérou :
admin@laborderie:~$ sudo dpkg --configure -a
dpkg: error: dpkg frontend lock was locked by another process with pid 19109
Note: removing the lock file is always wrong, and can end up damaging the
locked area and the entire system. See https://wiki.debian.org/Teams/Dpkg/FAQ.
le pid 19109 est lié à un upgrade de python3
root 19109 19076 0 May01 ? 00:44:57 /usr/bin/python3 /usr/bin/unattended-upgrade

Je redémarre le serveur ce qui résoud le problème, et je peut faire les commandes
sudo dpkg --audit
sudo dpkg --configure -a
sudo apt install --fix-broken
et la nouvelle version de mariadb se trouve correctement installé

ensuite je fais l’upgrade système puis des applis sans problème.

Voilà, merci pour le coup de main, et pour avoir développé tout ça, c’est super.

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