Discourse Erreur de passerelle après redémarrage

Soutien Installation
1

Mon serveur s’exécute dans une machine virtuelle hébergée par l’un des principaux fournisseurs de cloud.
J’ai installé discourse avec succès dessus et il fonctionne sans problème depuis un mois.
Aujourd’hui, j’ai décidé de revenir aux spécifications originales de ma VM (*) et de redémarrer. Au démarrage, alors que tout le reste sur mon serveur fonctionne correctement, j’obtiens une erreur 502 Bad Gateway lorsque j’essaie d’accéder au forum Discourse. Pensant que l’instance Docker ne s’était pas lancée automatiquement, je me suis connecté en SSH à mon serveur et j’ai exécuté ./launcher start app, mais j’ai reçu un message indiquant un espace insuffisant (5 Go disponibles). J’ai donc lancé df -h, qui m’indique que j’ai en réalité 14 Go disponibles. J’ai donc relancé ./launcher start app, mais cette fois, un avertissement m’a informé que Docker allait télécharger des éléments et qu’il fallait être patient. Après quelques traitements, le message Nothing to do, your container has already started! s’est affiché. Cependant, mes tentatives pour accéder au forum renvoyaient toujours 502 Bad Gateway.

Après avoir consulté ce forum, j’ai décidé d’exécuter ./launcher rebuild app et j’ai obtenu les erreurs suivantes, liées à PostgreSQL :

    user@host:[16:48]:/var/discourse# ./launcher rebuild app
    Ensuring launcher is up to date
    Fetching origin
    Launcher is up-to-date
    Stopping old container
    + /usr/bin/docker stop -t 60 app
    app
    cd /pups && git pull && /pups/bin/pups --stdin
    Already up to date.
    I, [2020-07-01T07:19:42.821347 #1]  INFO -- : Loading --stdin
    I, [2020-07-01T07:19:42.831806 #1]  INFO -- : > locale-gen $LANG && update-locale
    I, [2020-07-01T07:19:42.879007 #1]  INFO -- : Generating locales (this might take a while)...
    Generation complete.
    
    I, [2020-07-01T07:19:42.879431 #1]  INFO -- : > mkdir -p /shared/postgres_run
    I, [2020-07-01T07:19:42.885054 #1]  INFO -- :
    I, [2020-07-01T07:19:42.885734 #1]  INFO -- : > chown postgres:postgres /shared/postgres_run
    I, [2020-07-01T07:19:42.891657 #1]  INFO -- :
    I, [2020-07-01T07:19:42.892269 #1]  INFO -- : > chmod 775 /shared/postgres_run
    I, [2020-07-01T07:19:42.898103 #1]  INFO -- :
    I, [2020-07-01T07:19:42.898942 #1]  INFO -- : > rm -fr /var/run/postgresql
    I, [2020-07-01T07:19:42.905607 #1]  INFO -- :
    I, [2020-07-01T07:19:42.906463 #1]  INFO -- : > ln -s /shared/postgres_run /var/run/postgresql
    I, [2020-07-01T07:19:42.912617 #1]  INFO -- :
    I, [2020-07-01T07:19:42.913233 #1]  INFO -- : > socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
    2020/07/01 07:19:42 socat[26] E connect(6, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): No such file or directory
    I, [2020-07-01T07:19:42.925688 #1]  INFO -- :
    I, [2020-07-01T07:19:42.926081 #1]  INFO -- : > rm -fr /shared/postgres_run/.s*
    I, [2020-07-01T07:19:42.931174 #1]  INFO -- :
    I, [2020-07-01T07:19:42.931649 #1]  INFO -- : > rm -fr /shared/postgres_run/*.pid
    I, [2020-07-01T07:19:42.938154 #1]  INFO -- :
    I, [2020-07-01T07:19:42.938850 #1]  INFO -- : > mkdir -p /shared/postgres_run/12-main.pg_stat_tmp
    I, [2020-07-01T07:19:42.943575 #1]  INFO -- :
    I, [2020-07-01T07:19:42.944331 #1]  INFO -- : > chown postgres:postgres /shared/postgres_run/12-main.pg_stat_tmp
    I, [2020-07-01T07:19:42.949159 #1]  INFO -- :
    I, [2020-07-01T07:19:42.961190 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown:
    I, [2020-07-01T07:19:42.973345 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown:
    I, [2020-07-01T07:19:42.983929 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown:
    I, [2020-07-01T07:19:42.994843 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown:
    I, [2020-07-01T07:19:42.995487 #1]  INFO -- : > chown -R root /var/lib/postgresql/12/main
    I, [2020-07-01T07:19:44.012812 #1]  INFO -- :
    I, [2020-07-01T07:19:44.013656 #1]  INFO -- : > [ ! -e /shared/postgres_data ] && install -d -m 0755 -o postgres -g postgres /shared/postgres_data && sudo -E -u postgres /usr/lib/postgresql/12/bin/initdb -D /shared/postgres_data || exit 0
    I, [2020-07-01T07:19:44.019545 #1]  INFO -- :
    I, [2020-07-01T07:19:44.019872 #1]  INFO -- : > chown -R postgres:postgres /shared/postgres_data
    I, [2020-07-01T07:19:44.064432 #1]  INFO -- :
    I, [2020-07-01T07:19:44.065186 #1]  INFO -- : > chown -R postgres:postgres /var/run/postgresql
    I, [2020-07-01T07:19:44.071385 #1]  INFO -- :
    I, [2020-07-01T07:19:44.072196 #1]  INFO -- : > /root/upgrade_postgres
    I, [2020-07-01T07:19:44.084004 #1]  INFO -- :
    I, [2020-07-01T07:19:44.084662 #1]  INFO -- : > rm /root/upgrade_postgres
    I, [2020-07-01T07:19:44.090399 #1]  INFO -- :
    I, [2020-07-01T07:19:44.092280 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/12/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.093969 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.095204 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.095937 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.096695 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.097554 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.101971 #1]  INFO -- : > install -d -m 0755 -o postgres -g postgres /shared/postgres_backup
    I, [2020-07-01T07:19:44.112672 #1]  INFO -- :
    I, [2020-07-01T07:19:44.113831 #1]  INFO -- : Replacing (?-mix:#?max_wal_senders *=.*) with max_wal_senders = $db_max_wal_senders in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.114973 #1]  INFO -- : Replacing (?-mix:#?wal_level *=.*) with wal_level = $db_wal_level in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.116047 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.117033 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.118051 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.119352 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/12/main/pg_hba.conf
    I, [2020-07-01T07:19:44.120299 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/12/main/pg_hba.conf
    I, [2020-07-01T07:19:44.121038 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main
    I, [2020-07-01T07:19:44.126334 #1]  INFO -- : > sleep 5
    2020-07-01 07:19:44.157 UTC [49] LOG:  starting PostgreSQL 12.2 (Debian 12.2-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
    2020-07-01 07:19:44.158 UTC [49] LOG:  listening on IPv4 address "0.0.0.0", port 5432
    2020-07-01 07:19:44.158 UTC [49] LOG:  listening on IPv6 address "::", port 5432
    2020-07-01 07:19:44.161 UTC [49] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
    2020-07-01 07:19:44.162 UTC [49] FATAL:  could not map anonymous shared memory: Cannot allocate memory
    2020-07-01 07:19:44.162 UTC [49] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 4423172096 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
    2020-07-01 07:19:44.162 UTC [49] LOG:  database system is shut down
    I, [2020-07-01T07:19:49.141762 #1]  INFO -- :
    I, [2020-07-01T07:19:49.142221 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
    createdb: error: could not connect to database template1: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.227852 #1]  INFO -- :
    I, [2020-07-01T07:19:49.228226 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.330486 #1]  INFO -- :
    I, [2020-07-01T07:19:49.330822 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.425970 #1]  INFO -- :
    I, [2020-07-01T07:19:49.426356 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.506638 #1]  INFO -- :
    I, [2020-07-01T07:19:49.507202 #1]  INFO -- : Terminating async processes
    
    
    FAILED
    --------------------
    Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 75 exit 2>
    Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
    exec failed with the params "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
    eb41679f76cd749ccd8c84a7543365d093619b80df6fc6750b9349fb63565fa1
    ** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
    ./discourse-doctor may help diagnose the problem.
    user@host:[17:19]:/var/discourse#

Étrangement, malgré les erreurs ci-dessus, l’exécution de ./launcher start app ne produit aucune erreur :

starting up existing container
+ /usr/bin/docker start app
app

Avec l’instance en cours d’exécution, j’ai essayé d’utiliser ./launcher enter app pour accéder au conteneur. (À mon humble avis, les outils disponibles dans le conteneur sont très limités (oui, je suis un utilisateur de nano et j’aime avoir divers alias mappés ; par exemple ll). Je ne parviens pas à trouver le chemin physique vers les dossiers à l’intérieur de l’instance Docker (car je souhaiterais les télécharger via un client FTP).

Dans /var/log/nginx/error.log, j’ai l’entrée d’erreur suivante à chaque actualisation de mon navigateur :

2020/07/01 07:44:16 [error] 646#646: *3 connect() failed (111: Connection refused) while connecting to upstream, client: xxx.xx.0.1, server: _, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "discourse.myDomain.com"

Quelle pourrait être la cause de mon problème ? Pourquoi PostgreSQL ne fonctionne-t-il soudainement plus ?

(*) Une semaine après l’installation de Discourse, j’ai mis à niveau mon serveur avec plus de processeurs et de mémoire. J’avais besoin de cela pour une conférence vidéo que j’ai animée. Une fois la conférence terminée, je suis revenu à ma configuration normale. Notez que je n’ai modifié la taille des disques à aucun moment lors des changements de spécifications.

2

Cela est dû au fait que votre reconstruction actuelle du conteneur a échoué ; vous démarrez donc une version antérieure de votre app. C’est un comportement normal. Lorsqu’une reconstruction n’est pas couronnée de succès, le conteneur d’origine n’est généralement pas supprimé et l’image d’origine reste également disponible.

Concernant votre problème avec PG, vous devrez fournir à l’équipe plus de détails sur la configuration de votre application et de votre conteneur afin de bénéficier du meilleur support possible.

3

@neounix : Merci.

Je débute dans l’hébergement d’un forum Discourse, donc je ne suis pas sûr de savoir où chercher ni quoi surveiller. J’ai une installation essentiellement vanilla sans plugins ni autres modifications. J’ai défini certaines variables dans app.yml et j’utilise mon démon Apache2 existant comme proxy inverse pour rediriger le trafic Discourse, via un hôte virtuel séparé, vers le port localhost sur lequel Discourse est configuré pour écouter.
Pourriez-vous préciser quelles informations seraient utiles ? Existe-t-il une ressource que je pourrais consulter pour m’aider à déboguer ma situation ?

4

L’erreur principale se trouve dans le fichier de journal ci-dessus.

2020-07-01 07:19:44.162 UTC [49] FATAL:  échec du mappage de la mémoire partagée anonyme : Impossible d'allouer de la mémoire

2020-07-01 07:19:44.162 UTC [49] HINT:  Cette erreur signifie généralement que la demande de segment de mémoire partagée de PostgreSQL a dépassé la mémoire disponible, l'espace d'échange (swap) ou les pages géantes. Pour réduire la taille de la demande (actuellement 4423172096 octets), réduisez l'utilisation de la mémoire partagée par PostgreSQL, par exemple en diminuant shared_buffers ou max_connections.
5

J’ai vu cette erreur, mais je n’ai apporté aucune modification à app.yml. Où puis-je réduire shared_buffers ou max_connections, puisqu’ils ne figurent pas dans app.yml ? app.yml ne contient qu’un paramètre db_shared_buffers, mais il est défini sur la valeur par défaut « 4096 Mo », comme c’était toujours le cas (avant et après l’augmentation de la mémoire du serveur).

6

Vous devriez envisager de publier vos statistiques relatives à la mémoire.

Par exemple, sous Linux :

$ free -m
              total        used        free      shared  buff/cache   available
Mem:          64299       12955        9678         361       41664       50265
Swap:          7807          69        7738

et pour les statistiques Docker, publiez la sortie de

docker stats

etc.

L’erreur est liée à un manque de mémoire.

7

Les statistiques de mémoire du serveur sont :

              total        utilisé        libre      partagé  buff/cache   disponible
Mémoire:       3951        2236         414          86        1299        1308
Échange:        511         415          96

Statistiques de mémoire après enter app :

              total        utilisé        libre      partagé  buff/cache   disponible
Mémoire:       3951        2363         321          86        1266        1215
Échange:        511         415          96

L’exécution de docker stats > output.txt a produit :

        CONTAINER ID        NOM                 CPU %               UTILISATION MÉMOIRE / LIMIT   % MÉMOIRE               E/S RÉSEAU             E/S DISQUE           PIDS
       ca4c5f37894c        app                 15.86%              6.48MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NOM                 CPU %               UTILISATION MÉMOIRE / LIMIT   % MÉMOIRE               E/S RÉSEAU             E/S DISQUE           PIDS
       ca4c5f37894c        app                 15.86%              6.48MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NOM                 CPU %               UTILISATION MÉMOIRE / LIMIT     % MÉMOIRE               E/S RÉSEAU             E/S DISQUE           PIDS
       ca4c5f37894c        app                 2.83%               6.539MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NOM                 CPU %               UTILISATION MÉMOIRE / LIMIT     % MÉMOIRE               E/S RÉSEAU             E/S DISQUE           PIDS
       ca4c5f37894c        app                 2.83%               6.539MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NOM                 CPU %               UTILISATION MÉMOIRE / LIMIT     % MÉMOIRE               E/S RÉSEAU             E/S DISQUE           PIDS
       ca4c5f37894c        app                 3.30%               6.477MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NOM                 CPU %               UTILISATION MÉMOIRE / LIMIT     % MÉMOIRE               E/S RÉSEAU             E/S DISQUE           PIDS
       ca4c5f37894c        app                 3.30%               6.477MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NOM                 CPU %               UTILISATION MÉMOIRE / LIMIT     % MÉMOIRE               E/S RÉSEAU             E/S DISQUE           PIDS
       ca4c5f37894c        app                 2.45%               6.535MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NOM                 CPU %               UTILISATION MÉMOIRE / LIMIT     % MÉMOIRE               E/S RÉSEAU             E/S DISQUE           PIDS
       ca4c5f37894c        app                 2.45%               6.535MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
8

Bonjour @nap

Vous pouvez libérer beaucoup de mémoire en arrêtant puis en supprimant tous ces anciens conteneurs app.

Par exemple :

docker stop <container_id>
docker rm <container_id>

En supposant qu’ils ne sont pas en cours d’utilisation ?

Si tous sont en cours d’utilisation, vous devriez envisager d’augmenter la mémoire de ce serveur au-delà de 4 Go ; peut-être passer à 8 Go :slight_smile:

9

J’ai arrêté l’application avec ./launcher stop app, puis j’ai relancé docker stats. Aucun conteneur n’était listé.
Malheureusement, augmenter la mémoire implique de payer plus. Ce qui est frustrant pour le moment, c’est que cela fonctionnait le mois dernier avec 4 Go.

10

Et je ne suis même pas en mesure de recompiler pour le moment, ce qui ne devrait pas consommer autant de mémoire.

Sans le conteneur en cours d’exécution, les statistiques de mémoire sont les suivantes :

              total        used        free      shared  buff/cache   available
Mem:           3951        2207         169          91        1574        1332
Swap:           511         446          65

J’ai quelques répertoires intéressants dans ./var/lib/docker/overlay2/ :

e3e6cdfcc62c2e0b68ec91efxxxxx6c69212c95b5070f7b6b84e97edcb473ea2
64a04d1b97a18f51a5fdc536xxxxxf9473de0c2ccd1a2cc0d62e830164b5f2d8
355303c6af7bebff1163195c5xxxxx8fd1de6333e39adbcb573c7365673b6c85

Puis-je les supprimer ?

11

D’accord.

Je vois. J’étais occupé à travailler sur une autre tâche et n’ai pas remarqué que votre affichage montrait les statistiques pour le même conteneur et non pour plusieurs.

Que vous indique free -m maintenant que votre conteneur n’est pas en cours d’exécution ?

Je pense que les 4 Go de RAM sont suffisants pour un seul conteneur, c’est certain.

12

Non.

Ne supprimez pas ces fichiers Docker.

Le problème, d’après le message d’erreur, est lié à votre configuration Discourse PG 12. Je ne suis pas sûr de savoir comment le résoudre, car l’ajustement du fichier de configuration PG 12 pour Discourse n’est pas pris en charge, je pense.

Les experts du forum Meta auront de meilleures suggestions que moi, en particulier les équipes d’hébergement professionnel.

13

Ce que vous dites, c’est que cela est interne aux fichiers de la configuration Docker ? Et que le modifier manuellement entraînera des problèmes une fois le conteneur démarré ou mis à jour ?

14

@nap

Si vous effectuez une recherche Google avec le message d’erreur ci-dessus (entre guillemets), vous trouverez de nombreuses discussions directement pertinentes sur ce message d’erreur PostgreSQL exact.

J’espère que cela vous aidera.

15

Après avoir fait cela, avez-vous relancé ./discourse-setup ou modifié manuellement les paramètres de mémoire dans app.yml ? Que signifient db_shared_buffers, unicorn_workers et db_work_mem ?

Sauf que vous êtes derrière un proxy inverse, ce qui complique les choses. Il n’est pas clair que le proxy inverse soit en cause ici, mais cela rend la situation plus complexe.

Avez-vous plusieurs partitions ? Serait-il possible que la partition où Docker crée les images soit pleine ?

16

@pfaffman : Merci d’avoir pris le temps de jeter un coup d’œil.

Non, tout ce que j’ai fait, c’est ajouter une série de définitions de variables relatives au nom du site et à l’utilisation des tags.

db_shared_buffers est réglé à “4096MB”
unicorn_workers est réglé à 8
db_work_mem est commenté

J’ai une seule partition principale de 40 Go (14 Go libres), 512 Mo d’espace d’échange (swap) et une partition de 8 Go pour les sauvegardes (non montée).

Il semble que j’aie résolu le problème. Au début, j’ai essayé de réduire les tampons à 2 Go et les workers à 4, mais j’ai obtenu la même erreur. J’ai ensuite réduit les tampons à 1 Go, moment où rebuild a réussi et le forum est de nouveau en ligne.

Merci à tous !!