PnX-SI / GeoNature-atlas

Application WEB permettant de générer des fiches espèces publiques à partir d'observations faune/flore
GNU General Public License v3.0
44 stars 46 forks source link

[1.4.2 vers 1.5.1] Erreur 503 et pas de messages dans les logs #408

Closed JeromeMaruejouls closed 2 years ago

JeromeMaruejouls commented 2 years ago

Bonjour, Je tente une mise à jour vers la dernière version de Géonature Atlas. Installation sur le même serveur que Géonature. Un atlas en 1.4.2 fonctionne très bien. Après avoir suivi la procédure de mise à jour (classique + spécificité 1.5 avec passage de supervisor à sytemctl), j'ai une erreur 503 (servvuce unavailable). Le process est bien lancé (systemctl status =>running) et je n'ai pas d'erreur dans les logs.

J'ai tenté en mettant le modeDebug à True, mais pas plus d'infos (sauf si cela génère des logs ailleurs que dans /var/log/geonature-atlas ?)

Au premier lancement, j'ai eu une erreur sur le paramètre SPLIT_NOM_VERN qui était à True, comme dans le fichier d'exemple, mais qui doit être un Integer.

Avez vous une idée de comment résoudre le problème ? Vu l'erreur je ne pense pas que cela vienne d'apache, mais plutôt de l'application. Sans log, je suis un peu perdu. La bdd semble bien rempli (pas de soucis lors de sa création) et j'ai repris le fichier de conf de la 1.4.2 en ajoutant les champs du fichier d'exemple.

Merci d'avance.

mvergez commented 2 years ago

Bonjour, J'ai testé cette version et effectivement j'avais eu le même problème. SPLIT_NOM_VERN est à True par défaut donc tu peux tester en l'enlevant directement du fichier de configuration (config.py). C'est un bug dans cette version, SPLIT_NOM_VERN doit être défini comme booléen et non comme entier. Il faudrait que je fasse une contribution à ce sujet...

Autre chose : les logs sont maintenant dans /var/log/geonature-atlas.log si je ne dis pas de bêtises.

J'espère que cela t'aidera.

Bon courage !

jpm-cbna commented 2 years ago

j'ai une erreur 503 (service unavailable)

Cela signifie peut être que le service geonature-atlas n'est pas bien démarré. Essayer de redémarrer le service avec sudo systemctl restart geonature-atlas. Mais quand un service n'est pas démarré, c'est plutôt l'erreur 502 Bad Gateway que j'obtiens.

Au vue des informations concernant l'erreur 503 Service Unavailable, le problème est peut être plutôt au niveau du serveur web. Vous pouvez tenter de le redémarrer aussi. Essayer aussi de vérifier que le serveur n'a pas de problème d'espace disque avec sudo df -h ou mémoire avec sudo htop (l'installer avec sudo apt install htop).

Avec le passage à la version 1.5.0, le service Supervisord a été remplacé par une service SystemD. On peut:

JeromeMaruejouls commented 2 years ago

Merci @jpm-cbna et @mvergez pour vos réponses.

Concernant les services (apache et geonature-atlas), les deux tournent :

geonatureadmin@ns362030:~/atlas/atlas/configuration$ sudo systemctl status apache2.service ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2022-04-11 12:41:15 UTC; 17h ago Docs: https://httpd.apache.org/docs/2.4/ Process: 2088 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS) Main PID: 26784 (/usr/sbin/apach) Tasks: 55 (limit: 4915) Memory: 31.1M CGroup: /system.slice/apache2.service ├─ 2094 /usr/sbin/apache2 -k start ├─ 2095 /usr/sbin/apache2 -k start └─26784 /usr/sbin/apache2 -k start

avril 11 12:41:15 ns362030 systemd[1]: Starting The Apache HTTP Server... avril 11 12:41:15 ns362030 systemd[1]: Started The Apache HTTP Server. avril 12 00:00:44 ns362030 systemd[1]: Reloading The Apache HTTP Server. avril 12 00:00:44 ns362030 systemd[1]: Reloaded The Apache HTTP Server.

geonatureadmin@ns362030:~/atlas/atlas/configuration$ sudo systemctl status geonature-atlas.service 
● geonature-atlas.service - GeoNature Atlas
   Loaded: loaded (/etc/systemd/system/geonature-atlas.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-04-12 06:28:30 UTC; 9min ago
 Main PID: 4483 (gunicorn)
    Tasks: 5 (limit: 4915)
   Memory: 188.4M
   CGroup: /system.slice/geonature-atlas.service
           ├─4483 /home/geonatureadmin/atlas/venv/bin/python /home/geonatureadmin/atlas/venv/bin/gunicorn atlas.wsgi:app --name geonature-atlas --workers 4 --bind 127.0.0.1:8080 --timeout=30
           ├─4488 /home/geonatureadmin/atlas/venv/bin/python /home/geonatureadmin/atlas/venv/bin/gunicorn atlas.wsgi:app --name geonature-atlas --workers 4 --bind 127.0.0.1:8080 --timeout=30
           ├─4489 /home/geonatureadmin/atlas/venv/bin/python /home/geonatureadmin/atlas/venv/bin/gunicorn atlas.wsgi:app --name geonature-atlas --workers 4 --bind 127.0.0.1:8080 --timeout=30
           ├─4490 /home/geonatureadmin/atlas/venv/bin/python /home/geonatureadmin/atlas/venv/bin/gunicorn atlas.wsgi:app --name geonature-atlas --workers 4 --bind 127.0.0.1:8080 --timeout=30
           └─4491 /home/geonatureadmin/atlas/venv/bin/python /home/geonatureadmin/atlas/venv/bin/gunicorn atlas.wsgi:app --name geonature-atlas --workers 4 --bind 127.0.0.1:8080 --timeout=30

avril 12 06:28:30 ns362030 systemd[1]: Started GeoNature Atlas.

(Quand j'avais l'erreur du type de SPLIT_NOM_VERN, le service était en erreur)

Concernant la configuration Apache, je n'ai rien touché par rapport à la 1.4.2. Y a t il une modification à faire comme pour le passage à géonature 1.8 ? A noter que le service apache fonctionne bien car mon géonature sur le même serveur fonctionne normalement.

Pour les log, oui, j'ai bien vu qu'ils étaient maintenant dans /var/log
Voici les logs suitent à un restart du service : 

[2022-04-12 06:28:30 +0000] [32064] [INFO] Worker exiting (pid: 32064)
[2022-04-12 06:28:30 +0000] [32065] [INFO] Worker exiting (pid: 32065)
[2022-04-12 06:28:30 +0000] [32066] [INFO] Worker exiting (pid: 32066)
[2022-04-12 06:28:30 +0000] [32067] [INFO] Worker exiting (pid: 32067)
[2022-04-12 06:28:30 +0000] [32061] [INFO] Handling signal: term
[2022-04-12 06:28:30 +0000] [32061] [INFO] Shutting down: Master
[2022-04-12 06:28:31 +0000] [4483] [INFO] Starting gunicorn 20.1.0
[2022-04-12 06:28:31 +0000] [4483] [INFO] Listening at: http://127.0.0.1:8080 (4483)
[2022-04-12 06:28:31 +0000] [4483] [INFO] Using worker: sync
[2022-04-12 06:28:31 +0000] [4488] [INFO] Booting worker with pid: 4488
[2022-04-12 06:28:31 +0000] [4489] [INFO] Booting worker with pid: 4489
[2022-04-12 06:28:31 +0000] [4490] [INFO] Booting worker with pid: 4490
[2022-04-12 06:28:31 +0000] [4491] [INFO] Booting worker with pid: 4491

Et ceci, peu importe la valeur de la variable modeDebug dans le fichier config.py

Je ne sais pas vraiment où chercher... (hormis un problème apache, je ne vois pas, mais je ne pense pas que cela génèrerait une erreur 503)
JeromeMaruejouls commented 2 years ago

Infos supplémentaires : j'ai testé avec 2 fichiers configuration différents :

Dans les deux cas, erreur 503 avec ce message dans le navigateur :

Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache/2.4.38 (Debian) Server at xx.xxx.xxx.xxx Port 80

Pour info, voici ma conf dans sites-available (activé bien sûr)

Configuration GeoNature-atlas

    <Location /atlas>
            ProxyPass  http://xx.xxx.xxx.xxx:8080
            ProxyPassReverse  http://xx.xxx.xxx.xxx:8080
    </Location>

FIN Configuration GeoNature-atlas

mvergez commented 2 years ago

Bonjour, As-tu testé de mettre http://localhost:8080 au lieu de http://xx.xxx.xxx.xxx:8080 ? Comme ton atlas tourne sur le port 8080 de la machine sur laquelle est installée Apache il faut passer par localhost. Peux tu faire la commande suivante wget http://localhost:8080 (avec l'utilisateur linux courant) ? Cela permet de faire un appel à l'atlas pour récupérer le html et donc voir si l'atlas fonctionne bien et que cela vient bien de apache ou autre.

JeromeMaruejouls commented 2 years ago

Enorme merci @mvergez !!! C'était bien cela le problème !

Je note l'astuce pour cibler le problème sur apache ou sur l'atlas 👍

Par contre, ce que je ne m'explique pas, c'est que cela fonctionnait avec l'IP pour les anciennes versions de l'atlas.

Encore merci, je ferme le ticket en espérant qu'il serve à d'autres personnes à l'avenir.

jpm-cbna commented 2 years ago

Par contre, ce que je ne m'explique pas, c'est que cela fonctionnait avec l'IP pour les anciennes versions de l'atlas.

Dans la version 1.4.2, le service Gunicorn était lancé par défaut sur l'IP privée 0.0.0.0. Avec cette IP là, le service est accessible depuis l'extérieur du serveur. Donc indiquer l'IP du serveur dans la config Apache fonctionnait.

À partir de la version 1.5.0, le service Gunicorn lancé depuis le service SystemD est lancé sur l'IP privé 127.0.0.1. Or, sur cette IP le service n'est plus accessible depuis l'extérieur du serveur. Ce qui est mieux d'un point de vue de la sécurité du serveur. Il faut donc bien indiquer l'IP 127.0.0.1 ou son alias localhost dans la configuration d'Apache.

Si l'on souhaite toutefois continuer à utiliser l'IP 0.0.0.0, il suffit de créer un fichier environ à la racine du dossier de l'Atlas (là où se trouve le fichier setup.py) et y mettre dedans:

GUNICORN_HOST=0.0.0.0
JeromeMaruejouls commented 2 years ago

Par contre, ce que je ne m'explique pas, c'est que cela fonctionnait avec l'IP pour les anciennes versions de l'atlas.

Dans la version 1.4.2, le service Gunicorn était lancé par défaut sur l'IP privée 0.0.0.0. Avec cette IP là, le service est accessible depuis l'extérieur du serveur. Donc indiquer l'IP du serveur dans la config Apache fonctionnait.

À partir de la version 1.5.0, le service Gunicorn lancé depuis le service SystemD est lancé sur l'IP privé 127.0.0.1. Or, sur cette IP le service n'est plus accessible depuis l'extérieur du serveur. Ce qui est mieux d'un point de vue de la sécurité du serveur. Il faut donc bien indiquer l'IP 127.0.0.1 ou son alias localhost dans la configuration d'Apache.

Si l'on souhaite toutefois continuer à utiliser l'IP 0.0.0.0, il suffit de créer un fichier environ à la racine du dossier de l'Atlas (là où se trouve le fichier setup.py) et y mettre dedans:

GUNICORN_HOST=0.0.0.0

Cool, merci @jpm-cbna pour ces explications 👍