Tentative de sauvetage d'un serveur

Bonjour à tous,

Depuis hier j’essaye sans succès de sauver un serveur Yunohost qui m’a l’air d’être dans un sale état !
J’ai beaucoup de mal à comprendre d’où vient le problème, je vais essayer de vous faire un état des lieux le plus précis possible :

Version installée : 3.8.5.9 (fraîchement mise à jour depuis 3.0.x)
L’interface utilisateur et l’interface admin fonctionnent correctement
Nextcloud, la seule application installée, plante complètement (error 503)
Nextcloud est encore en version 13.x
Quand je lance un diagnostic dans l’interface admin, aucune erreur ne remonte
Quand je vérifie les services, tout est fonctionnel, y compris Nginx
Quand je clique sur Nginx pour avoir les détails, une erreur interne serveur apparaît (error 500)
La commande cat /var/log/nginx/errorl.og me donne :

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)

nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

nginx: [emerg] bind() to [::]:443 failed (98: Address already in use)

J’ai tenté de relancer Nginx, j’ai tenté les trucs du style sudo fuser -k 443/tcp mais sans succès !
Quand je clique sur Mysql, cette erreur apparaît toutes les deux secondes dans les journaux journalctl

Nov 04 13:45:03 mysqld[1212]: 2020-11-04 13:45:03 7f6a1ac47700 InnoDB: Error: Column last_update in table “mysql”.“innodb_table_stats” is INT UNSIGNED NOT NULL but should be BINARY(4) NOT NULL (type mismatch).

Par ailleurs la mise à jour de Nextcloud depuis 13.x en 19.x ne fonctionne pas - mais je doute qu’une mise à jour soit la meilleure des façons de résoudre mon problème…

Merci d’avance pour votre aide précieuse !

Comme de multiples messages dans sur ton interface et sur ce forum tentent despérément de le dire : si vous voulez de l’aide, filez les logs, BORDEL

Pareil.

Apriori le port 80 est lui aussi utilisé, donc regardons netstat -tupln | grep "80\|443"

Dans la mesure où ma tentative de mise à jour avait complètement effacé Nextcloud de mon système et que j’ai dû faire des restaurations pour revenir en arrière j’étais un peu frileux à l’idée de relancer le truc, désolé. Du coup je vais refaire une sauvegarde ovh puis lancer la mise à jour pour envoyer ici les logs. Envoi dans 5-10 minutes le temps de faire tout ça

Pour l’erreur 500 interne quand je clique sur le service Nginx, elle a vient de disparaître alors que je n’ai rien changé… à n’y rien comprendre

netstat -tupln | grep "80\|443" me donne :

tcp 0 0 0.0.0.0:8095 0.0.0.0:* LISTEN 8177/node
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 14690/nginx: worker
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 780/sshd
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 14690/nginx: worker
tcp6 0 0 :::80 :::* LISTEN 14690/nginx: worker
tcp6 0 0 :::22 :::* LISTEN 780/sshd
tcp6 0 0 :::443 :::* LISTEN 14690/nginx: worker
tcp6 0 0 :::9980 :::* LISTEN 735/loolwsd
udp6 0 0 fe80::f816:3eff:fe8:123 :::* 812/ntpd

Encore merci

Tu peux retrouver les logs de toutes les opérations passées dans Webadmin > Tools > Journals

@ljf merci je vais regarder, j’avais l’impression que ça n’était que pour les opérations lancées depuis l’administration web.

Voici les logs de la mise à jour plantée Nextcloud
https://paste.yunohost.org/raw/ofehaqegoq.bash

Merci encore,

2020-11-04 19:27:26,086: DEBUG - Nov 04 19:25:55 systemd[1]: Reloading Fail2Ban Service.
2020-11-04 19:27:26,086: DEBUG - Nov 04 19:27:25 systemd[1]: fail2ban.service: Reload operation timed out. Killing reload process.

Ça ressemble à un coup où fail2ban met trop de temps à se relancer. On a déjà vu le cas par le passé par exemple où certaines personnes ont changé le port SSH sans le propager sur la conf fail2ban. Est-ce que ce serait ton cas ?

Non, je n’ai rien changé !
Je n’avais simplement pas fait la migration Yunohost pour mettre à jour la configuration SSH. Je viens de le faire et de relancer la mise à jour de Nextcloud, les symptômes sont exactement les mêmes hélas.

On veut les logs. Parce que dit comme ça on ne sait pas si il y a une nouvelle erreur dans les logs (ou une en moins)

OK ok ça marche !
https://paste.yunohost.org/raw/ojeniqewuf.bash
Merci pour le temps passé

Que donne ces commandes dans cet ordre ?

systemctl status fail2ban
systemctl start fail2ban
systemctl status fail2ban

Si c’est start à la fin alors que ça l’était pas au début éssai de relancer l’upgrade.

Si ça ne marche pas, que donne :

journalctl -u fail2ban

Dans l’ordre :

admin@interface:~$ systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-11-05 10:14:26 UTC; 9h ago
Docs: man:fail2ban(1)
Main PID: 1404 (fail2ban-server)
Tasks: 21 (limit: 4915)
CGroup: /system.slice/fail2ban.service
└─1404 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b

admin@interface:~$ systemctl start fail2ban

Failed to start fail2ban.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files

See system logs and ‘systemctl status fail2ban.service’ for details.

admin@interface:~$ systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-11-05 10:14:26 UTC; 9h ago
Docs: man:fail2ban(1)
Main PID: 1404 (fail2ban-server)
Tasks: 21 (limit: 4915)
CGroup: /system.slice/fail2ban.service
└─1404 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b

Apparemment j’ai des problèmes de permissions

admin@interface:~$ journalctl -u fail2ban
Hint: You are currently not seeing messages from other users and the system.
Users in the ‘systemd-journal’ group can see all messages. Pass -q to
turn off this notice.
No journal files were opened due to insufficient permissions.

Tout ça est encore un peu cryptique pour moi !

Refait la même chose mais avec sudo devant chaque commande

admin@interface:~$ sudo systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-11-05 10:14:26 UTC; 11h ago
Docs: man:fail2ban(1)
Main PID: 1404 (fail2ban-server)
Tasks: 21 (limit: 4915)
CGroup: /system.slice/fail2ban.service
└─1404 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b

Nov 05 10:14:20 interface.monserveur.com systemd[1]: Starting Fail2Ban Service…
Nov 05 10:14:23 interface.monserveur.com fail2ban-client[1063]: 2020-11-05 10:14:23,516 fail2ban.server [1281]: INFO Starting Fail2ban v0.9.6
Nov 05 10:14:23 interface.monserveur.com fail2ban-client[1063]: 2020-11-05 10:14:23,529 fail2ban.server [1281]: INFO Starting in daemon mode
Nov 05 10:14:25 interface.monserveur.com systemd[1]: fail2ban.service: Unit cannot be reloaded because it is inactive.

admin@interface:~$ sudo systemctl start fail2ban

Pas de retour suite à cette commande

admin@interface:~$ sudo systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-11-05 10:14:26 UTC; 11h ago
Docs: man:fail2ban(1)
Main PID: 1404 (fail2ban-server)
Tasks: 21 (limit: 4915)
CGroup: /system.slice/fail2ban.service
└─1404 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b

Nov 05 10:14:20 interface.monserveur.com systemd[1]: Starting Fail2Ban Service…
Nov 05 10:14:23 interface.monserveur.com fail2ban-client[1063]: 2020-11-05 10:14:23,516 fail2ban.server [1281]: INFO Starting Fail2ban v0.9.6
Nov 05 10:14:23 interface.monserveur.com fail2ban-client[1063]: 2020-11-05 10:14:23,529 fail2ban.server [1281]: INFO Starting in daemon mode
Nov 05 10:14:25 interface.monserveur.com systemd[1]: fail2ban.service: Unit cannot be reloaded because it is inactive.

Merci !

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